netdev - Re: [PATCH net v2 1/1] i40e: xsk: advance next_to

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aPkGKqZjauLHYfka@lima-default>
Date: Thu, 23 Oct 2025 03:28:26 +1100
From: Your Name <alessandro.d@...il.com>
To: "Sarkar, Tirthendu" <tirthendu.sarkar@...el.com>
Cc: Jason Xing <kerneljasonxing@...il.com>,
	Alessandro Decina <alessandro.d@...il.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"Fijalkowski, Maciej" <maciej.fijalkowski@...el.com>,
	"David S. Miller" <davem@...emloft.net>,
	Alexei Starovoitov <ast@...nel.org>,
	Andrew Lunn <andrew+netdev@...n.ch>,
	Daniel Borkmann <daniel@...earbox.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>,
	Jesper Dangaard Brouer <hawk@...nel.org>,
	John Fastabend <john.fastabend@...il.com>,
	Paolo Abeni <pabeni@...hat.com>,
	"Kitszel, Przemyslaw" <przemyslaw.kitszel@...el.com>,
	Stanislav Fomichev <sdf@...ichev.me>,
	"Nguyen, Anthony L" <anthony.l.nguyen@...el.com>,
	"bpf@...r.kernel.org" <bpf@...r.kernel.org>,
	"intel-wired-lan@...ts.osuosl.org" <intel-wired-lan@...ts.osuosl.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net v2 1/1] i40e: xsk: advance next_to_clean on status
 descriptors

On Wed, Oct 22, 2025 at 05:41:06AM +0000, Sarkar, Tirthendu wrote:
> > From: Jason Xing <kerneljasonxing@...il.com>
> 
> I believe the issue is not that status_descriptor is getting into
> multi-buffer packet but not updating next_to_clean results in
> I40E_DESC_UNUSED() to return incorrect values.

I don't think this is true? next_to_clean can be < next_to_process by
design, see

	if (next_to_process != next_to_clean)
		first = *i40e_rx_bi(rx_ring, next_to_clean);

at the start of i40e_clean_rx_irq_zc. This condition is normal and means
when we exited the function - for example because we ran out of budget - 
we were in the middle of a multi-buffer packet and now we must continue.

If I understand the code, I think that in that case we just set
entries_to_alloc to a lower number and return fewer buffers to the
hardware. 


> A similar issue was
> reported and fixed on the non-ZC path:
> https://lore.kernel.org/netdev/20231004083454.20143-1-tirthendu.sarkar@intel.com/

This is indeed exactly the same issue, but I'm not yet sold on the
diagnosis :D 

Ciao,
Alessandro