linux-kernel - Re: [PATCH net-next 1/4] tun: rcu_deference xdp

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: <681cb21f4616e_2574d5294b3@willemb.c.googlers.com.notmuch>
Date: Thu, 08 May 2025 09:31:11 -0400
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: Jon Kohler <jon@...anix.com>, 
 Willem de Bruijn <willemdebruijn.kernel@...il.com>
Cc: "ast@...nel.org" <ast@...nel.org>, 
 "daniel@...earbox.net" <daniel@...earbox.net>, 
 "davem@...emloft.net" <davem@...emloft.net>, 
 "kuba@...nel.org" <kuba@...nel.org>, 
 "hawk@...nel.org" <hawk@...nel.org>, 
 "john.fastabend@...il.com" <john.fastabend@...il.com>, 
 "netdev@...r.kernel.org" <netdev@...r.kernel.org>, 
 "bpf@...r.kernel.org" <bpf@...r.kernel.org>, 
 "aleksander.lobakin@...el.com" <aleksander.lobakin@...el.com>, 
 Jason Wang <jasowang@...hat.com>, 
 Andrew Lunn <andrew+netdev@...n.ch>, 
 Eric Dumazet <edumazet@...gle.com>, 
 Paolo Abeni <pabeni@...hat.com>, 
 open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net-next 1/4] tun: rcu_deference xdp_prog only once per
 batch

Jon Kohler wrote:
> 
> 
> > On May 7, 2025, at 4:43 PM, Willem de Bruijn <willemdebruijn.kernel@...il.com> wrote:
> > 
> > !-------------------------------------------------------------------|
> >  CAUTION: External Email
> > 
> > |-------------------------------------------------------------------!
> > 
> > Jon Kohler wrote:
> >> Hoist rcu_dereference(tun->xdp_prog) out of tun_xdp_one, so that
> >> rcu_deference is called once during batch processing.
> > 
> > I'm skeptical that this does anything.
> > 
> > The compiler can inline tun_xdp_one and indeed seems to do so. And
> > then it can cache the read in a register if that is the best use of
> > a register.
> 
> The thought here is that if a compiler decided to not-inline tun_xdp_one
> (perhaps it grew to big, or the compiler was being sassy), that the intent
> would simply be that this wants to be called once-and-only-once. This
> change just makes that intent more clear, and is a nice little cleanup.
> 
> I’ve got a series that stacks on top of this that enables multi-buffer support
> and I can keep an eye on if that gets inlined or not.

That will only give you one outcome with a specific compiler, platform
and build configuration.

I would just drop this and let the compiler handle such optimizations.