From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E823029AAEA for ; Mon, 23 Mar 2026 08:37:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774255057; cv=none; b=LrsNiHdLyr8H2bt2CqIYnQbIr1kUGPcLhHNb/O2RHjy2ZYDtjkDXVh4yIdSu/8nrAwS8sT/8khn9fosmoURzc0YBWBFw7vH53oROCBvn3oGt9i5L3mWPKVoNj05Q963dd/DUpBsGUzS2JAbWkXjF4hQBispwMjdEs2ZOTlknXSs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774255057; c=relaxed/simple; bh=kV9qxt9z5kUBnQypg0tvwqy0X1j74YUSzCnUnCVOp0A=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=MMqmU9+nCGGIBI6hqgodGJ0/6MX5RfKnlT7TY6blzxk1Cx7HfFarGY8plbaw/C716AbECd7Y7+FUrK6pfwvRbR5W+pcIeoKjB6zU2p9z6USL2lTSguY06vOTelwiPUO3mWQXCp1TCao/K1seZXMGQIwhNsKN5MKaSCFazS0/7U8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=SdMqp++q; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=Ztb6sEgO; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="SdMqp++q"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="Ztb6sEgO" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1774255055; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=PTAb3BalGSZwPh5wtxjIj5LdP1IEByYqFV8DXSZ3Z9E=; b=SdMqp++qFznP07OtQqaCaJsH5MjAHpjLRLCTu6Hc2BHulXvJ/9Dh3z8fO88+Yx59GH2yDE obk+1o4pj69p7LWkhEeKx+fvOkzRy/ZIOqR21Q3A7dV6HSulo0RpY4Epx1c9MDONHlNeZu TEe/iZULBL+ftJqY4Ok/jIQS/QTPiIQ= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-711-vuBS9kdsP9-DGst7foDbuQ-1; Mon, 23 Mar 2026 04:37:33 -0400 X-MC-Unique: vuBS9kdsP9-DGst7foDbuQ-1 X-Mimecast-MFC-AGG-ID: vuBS9kdsP9-DGst7foDbuQ_1774255052 Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-48378df3469so32370585e9.1 for ; Mon, 23 Mar 2026 01:37:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1774255052; x=1774859852; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=PTAb3BalGSZwPh5wtxjIj5LdP1IEByYqFV8DXSZ3Z9E=; b=Ztb6sEgO9wZpyoAHxVPVq7AfwYtNLOjkOC1smkvVO7eMyjzMIaEvb3mV2m+OxqSnbU YXJW25T+7bDWZcsbdhI4BzD54vZ7krINRRFPPEW3u8WsVxmg5VTf4pUn9KmwPsgjZ6EA NQ/aVXMpx5cQ2HsU9i3WTczRrmct2p/AxiEPF7zUGLPXQOTYfNHQHJNKx9X0a6tT6/Bw l0uRjpAoDjE8G+oryLpq/Y8804uj1gMYJdIl47OCUxPO3MLcHocRJCf/rUKcfmJLMvOQ /B272nzZDwspSsiCy5Sgv3DSD24thMIGK7ENAOTx/Ty6z/nPyEXULrdBUXUypl6h6kJ6 0BTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774255052; x=1774859852; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=PTAb3BalGSZwPh5wtxjIj5LdP1IEByYqFV8DXSZ3Z9E=; b=lhJgF5eIbHJljM8g/Ic0p5d8ewGuJ/R6Tuh/zC1JqR7ara7dZ3Y7cGx/zjdbk72z97 /6v0mY2H98ccKqWM/mn7d6bNuBdCh3V14Pxow/MLsx0kESbqDP/BiwhCzEQp6JvSmaVL 5ZgVGleQjHqikhdu+8FGWLTpY0kp9nS2IZNwtqZhSC1/HDHckOGKezCHxuX8D+zdLfrg JoXpVm9Mi6eW/Zwy/V2OYOVkyKRamq8GAMlmlxYxyhK3JvfKwyLJaTKoccyd3WxsAY3j dEaeJSGtT/W1yqufZfHqUUIXhpihAc7G2qFadyiKYo6Q61OysvHuwbb0Qt+863j8DYVc Ob0w== X-Forwarded-Encrypted: i=1; AJvYcCVOEulqEIjfd5zIENmR3PSVrlZT5Vx8JW1aTmqC247104sBnHluX9Ro1grbeHD8Q0/XjUs3diGPHvSg2Fw=@vger.kernel.org X-Gm-Message-State: AOJu0YzxPLXvlkn7n1gtG25b3GDQbdz+V8sAD+HXoAOH5Qs94cpMYIjL 8MIxgyhNvJAMxR+2oClYuga8CUpMO+ruSx7Xil741Skyr1iwKcVYOmkbLiQuKgfSZ8zZLf4C7YC spm09Vo1iScR0W5+rsX2orVDQpNV18reJdfOEOkqWDcn6myHRTSrVceUv94eGpn+1Rg== X-Gm-Gg: ATEYQzyudN3etaQZC8GAc+jitkZgdX4My/meg8977rK8O3K6bLraODqeLr1S2JTcDQ3 DmMPHmiWT8HFlxO27FsiHV5JrvRAfLScAQ5sDE9h7VHUy8JkxVfgZCMBFBPeY5do8M4LfzrByVP gg/7dUh/W80CL+eFnlkED6CCfwipYQBhNtrAHa3QQo2kl3O4+ODiYad6uHxs8YKVPUrh02y/zoG QYPOQj0RpwObAjK9MTSklJGV3rXVTu9bCP6zAdK+mZjHQq58n1PEgWZeu98Z3bbRSVJsgjUHHjO 4y/JYAsL8cWMEih4KoM5dXzcYVxJarPFDDuVkSWa4wt5c1AAAT6Yp0pwGu21COHHazo7pMNF/pv q2oralFGQhZXJhtYr3l91 X-Received: by 2002:a05:600c:3b94:b0:486:faa8:9e4 with SMTP id 5b1f17b1804b1-486fe8ef087mr180279295e9.12.1774255051977; Mon, 23 Mar 2026 01:37:31 -0700 (PDT) X-Received: by 2002:a05:600c:3b94:b0:486:faa8:9e4 with SMTP id 5b1f17b1804b1-486fe8ef087mr180278855e9.12.1774255051520; Mon, 23 Mar 2026 01:37:31 -0700 (PDT) Received: from [192.168.2.83] ([46.175.183.46]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-486fe879d37sm98149575e9.1.2026.03.23.01.37.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 23 Mar 2026 01:37:30 -0700 (PDT) Message-ID: Date: Mon, 23 Mar 2026 09:37:29 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [Intel-wired-lan] [PATCH iwl-net] iavf: fix wrong VLAN mask for legacy Rx descriptors L2TAG2 To: Paul Menzel Cc: Przemek Kitszel , Eric Dumazet , linux-kernel@vger.kernel.org, Andrew Lunn , Tony Nguyen , Mateusz Polchlopek , Jacob Keller , Jakub Kicinski , Paolo Abeni , "David S. Miller" , intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org References: <20260320135326.1171433-1-poros@redhat.com> <310379eb-9b99-444d-bf02-2bde3bd79374@molgen.mpg.de> Content-Language: en-US From: Petr Oros In-Reply-To: <310379eb-9b99-444d-bf02-2bde3bd79374@molgen.mpg.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 3/20/26 15:29, Paul Menzel wrote: > Dear Petr, > > > Thank you for your patch. > > Am 20.03.26 um 14:53 schrieb Petr Oros: >> The IAVF_RXD_LEGACY_L2TAG2_M mask was incorrectly defined as >> GENMASK_ULL(63, 32), extracting 32 bits from qw2 instead of the >> 16-bit VLAN tag. In the legacy Rx descriptor layout, the 2nd L2TAG2 >> (VLAN tag) occupies bits 63:48 of qw2, not 63:32. >> >> The oversized mask causes FIELD_GET to return a 32-bit value where the >> actual VLAN tag sits in bits 31:16. When this value is passed to >> iavf_receive_skb() as a u16 parameter, it gets truncated to the lower >> 16 bits (which contain the 1st L2TAG2, typically zero). As a result, >> __vlan_hwaccel_put_tag() is never called and software VLAN interfaces >> on VFs receive no traffic. >> >> This affects VFs behind ice PF (VIRTCHNL VLAN v2) when the PF >> advertises VLAN stripping into L2TAG2_2 and legacy descriptors are >> used. >> >> The flex descriptor path already uses the correct mask >> (IAVF_RXD_FLEX_L2TAG2_2_M = GENMASK_ULL(63, 48)). > > Do you have a reproducer to verify the fix? Yes, i have  1. Create 2 VFs on ice PF (echo 2 > sriov_numvfs)  2. Disable spoofchk on both VFs  3. Move each VF into a separate network namespace  4. On each VF: create VLAN interface (e.g. vlan 198), assign IP, bring up  5. Set rx-vlan-offload OFF on both VFs  6. Ping between VLAN interfaces → expect PASS      (VLAN tag stays in packet data, kernel matches in-band)  7. Set rx-vlan-offload ON on both VFs  8. Ping between VLAN interfaces → expect FAIL if bug present      (HW strips VLAN tag into descriptor L2TAG2 field,       wrong mask extracts bits 47:32 instead of 63:48,       truncated to u16 → zero, __vlan_hwaccel_put_tag() never called,       packet delivered to parent interface, not VLAN interface) > >> Fixes: 2dc8e7c36d80 ("iavf: refactor iavf_clean_rx_irq to support >> legacy and flex descriptors") > > (That first entered Linux v6.15-rc1, and Linux 6.12 and 6.18 are LTS > series.) > The reproducer works but requires legacy Rx descriptors to be in use. On modern ice + iavf with full PTP support, flex descriptors are always negotiated and the buggy legacy path is never reached. Flex descriptors require all of the following:   - CONFIG_PTP_1588_CLOCK enabled in kernel config   - VIRTCHNL_VF_OFFLOAD_RX_FLEX_DESC granted by PF   - PTP capabilities negotiated (VIRTCHNL_VF_CAP_PTP)   - VIRTCHNL_1588_PTP_CAP_RX_TSTAMP supported   - VIRTCHNL_RXDID_2_FLEX_SQ_NIC present in DDP profile If any of these conditions is not met, iavf_select_rx_desc_format() falls back to legacy descriptors (RXDID=1) and the wrong L2TAG2 mask is hit. In our kernel we ended up in a state where the iavf Rx path refactor was backported but the full PTP support chain was not. Without PTP, iavf_ptp_cap_supported() returns false and flex descriptors are never selected, exposing the bug. Regards, Petr >> Signed-off-by: Petr Oros >> --- >>   drivers/net/ethernet/intel/iavf/iavf_type.h | 2 +- >>   1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/net/ethernet/intel/iavf/iavf_type.h >> b/drivers/net/ethernet/intel/iavf/iavf_type.h >> index 1d8cf29cb65ac5..5bb1de1cfd33b1 100644 >> --- a/drivers/net/ethernet/intel/iavf/iavf_type.h >> +++ b/drivers/net/ethernet/intel/iavf/iavf_type.h >> @@ -277,7 +277,7 @@ struct iavf_rx_desc { >>   /* L2 Tag 2 Presence */ >>   #define IAVF_RXD_LEGACY_L2TAG2P_M        BIT(0) >>   /* Stripped S-TAG VLAN from the receive packet */ >> -#define IAVF_RXD_LEGACY_L2TAG2_M        GENMASK_ULL(63, 32) >> +#define IAVF_RXD_LEGACY_L2TAG2_M        GENMASK_ULL(63, 48) >>   /* Stripped S-TAG VLAN from the receive packet */ >>   #define IAVF_RXD_FLEX_L2TAG2_2_M        GENMASK_ULL(63, 48) >>   /* The packet is a UDP tunneled packet */ > > Nice find. > > Reviewed-by: Paul Menzel > > > Kind regards, > > Paul >