From: Alexander Lobakin <aleksander.lobakin@intel.com>
To: Steve Rutherford <srutherford@google.com>,
Tony Nguyen <anthony.l.nguyen@intel.com>,
Przemek Kitszel <przemyslaw.kitszel@intel.com>,
"David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>,
Eric Dumazet <edumazet@google.com>,
<intel-wired-lan@lists.osuosl.org>
Cc: <netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
David Decotigny <decot@google.com>,
Anjali Singhai <anjali.singhai@intel.com>,
"Sridhar Samudrala" <sridhar.samudrala@intel.com>,
Brian Vazquez <brianvv@google.com>, Li Li <boolli@google.com>,
<emil.s.tantilov@intel.com>
Subject: Re: [Intel-wired-lan] [RFC PATCHv2 1/1] idpf: Fix header clobber in IDPF with SWIOTLB enabled
Date: Tue, 3 Mar 2026 16:31:50 +0100 [thread overview]
Message-ID: <6a7fbafa-cdcd-4bfa-ac00-204e68602f61@intel.com> (raw)
In-Reply-To: <20260227203457.558196-2-srutherford@google.com>
From: Steve Rutherford <srutherford@google.com>
Date: Fri, 27 Feb 2026 20:34:57 +0000
> When SWIOTLB and header split are enabled, IDPF sees empty packets in the
> rx queue.
>
> This is caused by libeth_rx_sync_for_cpu clobbering the synthesized header
> in the workaround (i.e. overflow) path. After the header is synthesized by
> idpf_rx_hsplit_wa, the sync call pulls from the empty SWIOTLB buffer,
> effectively zeroing out the buffer.
>
> This skips the extra sync in the workaround path in most cases. The one
> exception is that it calls sync to trigger a recycle the header buffer when
> it fails to find a header in the payload.
>
> Fixes: 90912f9f4f2d1 ("idpf: convert header split mode to libeth + napi_build_skb()")
> Signed-off-by: Steve Rutherford <srutherford@google.com>
> ---
> drivers/net/ethernet/intel/idpf/idpf_txrx.c | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/idpf/idpf_txrx.c b/drivers/net/ethernet/intel/idpf/idpf_txrx.c
> index 3ddf7b1e85ef..946203a6bd86 100644
> --- a/drivers/net/ethernet/intel/idpf/idpf_txrx.c
> +++ b/drivers/net/ethernet/intel/idpf/idpf_txrx.c
> @@ -3007,9 +3007,14 @@ static int idpf_rx_splitq_clean(struct idpf_rx_queue *rxq, int budget)
> u64_stats_update_begin(&rxq->stats_sync);
> u64_stats_inc(&rxq->q_stats.hsplit_buf_ovf);
> u64_stats_update_end(&rxq->stats_sync);
> - }
>
> - if (libeth_rx_sync_for_cpu(hdr, hdr_len)) {
> + /* Recycle the hdr buffer if unused.*/
> + if (!hdr_len)
> + libeth_rx_sync_for_cpu(hdr, 0);
> + } else if (!libeth_rx_sync_for_cpu(hdr, hdr_len))
> + hdr_len = 0;
> +
> + if (hdr_len) {
This is for a very old tree I believe? We now have
libeth_xdp_process_buff() there for quite some time already.
> skb = idpf_rx_build_skb(hdr, hdr_len);
> if (!skb)
> break;
Thanks,
Olek
WARNING: multiple messages have this Message-ID (diff)
From: Alexander Lobakin <aleksander.lobakin@intel.com>
To: Steve Rutherford <srutherford@google.com>,
Tony Nguyen <anthony.l.nguyen@intel.com>,
Przemek Kitszel <przemyslaw.kitszel@intel.com>,
"David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>,
Eric Dumazet <edumazet@google.com>,
<intel-wired-lan@lists.osuosl.org>
Cc: <netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
David Decotigny <decot@google.com>,
Anjali Singhai <anjali.singhai@intel.com>,
"Sridhar Samudrala" <sridhar.samudrala@intel.com>,
Brian Vazquez <brianvv@google.com>, Li Li <boolli@google.com>,
<emil.s.tantilov@intel.com>
Subject: Re: [RFC PATCHv2 1/1] idpf: Fix header clobber in IDPF with SWIOTLB enabled
Date: Tue, 3 Mar 2026 16:31:50 +0100 [thread overview]
Message-ID: <6a7fbafa-cdcd-4bfa-ac00-204e68602f61@intel.com> (raw)
In-Reply-To: <20260227203457.558196-2-srutherford@google.com>
From: Steve Rutherford <srutherford@google.com>
Date: Fri, 27 Feb 2026 20:34:57 +0000
> When SWIOTLB and header split are enabled, IDPF sees empty packets in the
> rx queue.
>
> This is caused by libeth_rx_sync_for_cpu clobbering the synthesized header
> in the workaround (i.e. overflow) path. After the header is synthesized by
> idpf_rx_hsplit_wa, the sync call pulls from the empty SWIOTLB buffer,
> effectively zeroing out the buffer.
>
> This skips the extra sync in the workaround path in most cases. The one
> exception is that it calls sync to trigger a recycle the header buffer when
> it fails to find a header in the payload.
>
> Fixes: 90912f9f4f2d1 ("idpf: convert header split mode to libeth + napi_build_skb()")
> Signed-off-by: Steve Rutherford <srutherford@google.com>
> ---
> drivers/net/ethernet/intel/idpf/idpf_txrx.c | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/idpf/idpf_txrx.c b/drivers/net/ethernet/intel/idpf/idpf_txrx.c
> index 3ddf7b1e85ef..946203a6bd86 100644
> --- a/drivers/net/ethernet/intel/idpf/idpf_txrx.c
> +++ b/drivers/net/ethernet/intel/idpf/idpf_txrx.c
> @@ -3007,9 +3007,14 @@ static int idpf_rx_splitq_clean(struct idpf_rx_queue *rxq, int budget)
> u64_stats_update_begin(&rxq->stats_sync);
> u64_stats_inc(&rxq->q_stats.hsplit_buf_ovf);
> u64_stats_update_end(&rxq->stats_sync);
> - }
>
> - if (libeth_rx_sync_for_cpu(hdr, hdr_len)) {
> + /* Recycle the hdr buffer if unused.*/
> + if (!hdr_len)
> + libeth_rx_sync_for_cpu(hdr, 0);
> + } else if (!libeth_rx_sync_for_cpu(hdr, hdr_len))
> + hdr_len = 0;
> +
> + if (hdr_len) {
This is for a very old tree I believe? We now have
libeth_xdp_process_buff() there for quite some time already.
> skb = idpf_rx_build_skb(hdr, hdr_len);
> if (!skb)
> break;
Thanks,
Olek
next prev parent reply other threads:[~2026-03-03 15:34 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-27 20:34 [Intel-wired-lan] [RFC PATCHv2 0/1] idpf: IDPF + SWIOTLB Bug Steve Rutherford via Intel-wired-lan
2026-02-27 20:34 ` Steve Rutherford
2026-02-27 20:34 ` [Intel-wired-lan] [RFC PATCHv2 1/1] idpf: Fix header clobber in IDPF with SWIOTLB enabled Steve Rutherford
2026-02-27 20:34 ` Steve Rutherford
2026-03-02 7:17 ` [Intel-wired-lan] " Loktionov, Aleksandr
2026-03-02 7:17 ` Loktionov, Aleksandr
2026-03-03 15:31 ` Alexander Lobakin [this message]
2026-03-03 15:31 ` Alexander Lobakin
2026-03-03 19:44 ` [Intel-wired-lan] " Steve Rutherford via Intel-wired-lan
2026-03-03 19:44 ` Steve Rutherford
2026-03-04 15:11 ` [Intel-wired-lan] " Alexander Lobakin
2026-03-04 15:11 ` Alexander Lobakin
2026-03-04 22:01 ` [Intel-wired-lan] " Steve Rutherford via Intel-wired-lan
2026-03-04 22:01 ` Steve Rutherford
2026-03-06 14:50 ` [Intel-wired-lan] " Alexander Lobakin
2026-03-06 14:50 ` Alexander Lobakin
2026-03-06 19:35 ` [Intel-wired-lan] " Steve Rutherford via Intel-wired-lan
2026-03-06 19:35 ` Steve Rutherford
2026-03-12 16:30 ` [Intel-wired-lan] " Alexander Lobakin
2026-03-12 16:30 ` Alexander Lobakin
2026-03-23 13:31 ` [Intel-wired-lan] " Alexander Lobakin
2026-03-23 13:31 ` Alexander Lobakin
2026-03-25 0:44 ` [Intel-wired-lan] " Steve Rutherford via Intel-wired-lan
2026-03-25 0:44 ` Steve Rutherford
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6a7fbafa-cdcd-4bfa-ac00-204e68602f61@intel.com \
--to=aleksander.lobakin@intel.com \
--cc=anjali.singhai@intel.com \
--cc=anthony.l.nguyen@intel.com \
--cc=boolli@google.com \
--cc=brianvv@google.com \
--cc=davem@davemloft.net \
--cc=decot@google.com \
--cc=edumazet@google.com \
--cc=emil.s.tantilov@intel.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=przemyslaw.kitszel@intel.com \
--cc=sridhar.samudrala@intel.com \
--cc=srutherford@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.