netdev - Re: [PATCH net-next v2] xsk: skip validating skb list in xmit path

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: <20250716175248.4f626bdb@kernel.org>
Date: Wed, 16 Jul 2025 17:52:48 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Jason Xing <kerneljasonxing@...il.com>
Cc: davem@...emloft.net, edumazet@...gle.com, pabeni@...hat.com,
 bjorn@...nel.org, magnus.karlsson@...el.com, maciej.fijalkowski@...el.com,
 jonathan.lemon@...il.com, sdf@...ichev.me, ast@...nel.org,
 daniel@...earbox.net, hawk@...nel.org, john.fastabend@...il.com,
 joe@...a.to, willemdebruijn.kernel@...il.com, bpf@...r.kernel.org,
 netdev@...r.kernel.org, Jason Xing <kernelxing@...cent.com>
Subject: Re: [PATCH net-next v2] xsk: skip validating skb list in xmit path

On Thu, 17 Jul 2025 08:06:48 +0800 Jason Xing wrote:
> To be honest, this patch really only does one thing as the commit
> says. It might look very complex, but if readers take a deep look they
> will find only one removal of that validation for xsk in the hot path.
> Nothing more and nothing less. So IMHO, it doesn't bring more complex
> codes here.
> 
> And removal of one validation indeed contributes to the transmission.
> I believe there remain a number of applications using copy mode
> currently. And maintainers of xsk don't regard copy mode as orphaned,
> right?

First of all, I'm not sure the patch is correct. The XSK skbs can have
frags, if device doesn't support or clears _SG we should linearize,
right?

Second, we don't understand where the win is coming from, the numbers
you share are a bit vague. What's so expensive about a few skbs
accesses? Maybe there's an optimization possible to the validation,
which would apply more broadly, instead of skipping it for one trivial
case.

Third, I asked you to compare with AF_PACKET, because IIUC it should
have similar properties as AF_XDP in copy mode. So why not use that?

Lastly, the patch is not all that bad, sure. But the experience of
supporting generic XDP is a very mixed. All the paths that pretend
to do XDP on skbs have a bunch of quirks and bugs. I'd prefer that
we push back more broadly on any sort of pretend XDP.