netdev - Re: [PATCH iwl-next v2 0/4] igb: XDP/ZC follow up

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: <Z7jnxolsaLICS6zD@LQ3V64L9R2>
Date: Fri, 21 Feb 2025 15:53:26 -0500
From: Joe Damato <jdamato@...tly.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Kurt Kanzenbach <kurt@...utronix.de>,
	Tony Nguyen <anthony.l.nguyen@...el.com>,
	Przemek Kitszel <przemyslaw.kitszel@...el.com>,
	Andrew Lunn <andrew+netdev@...n.ch>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>,
	Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
	Gerhard Engleder <gerhard@...leder-embedded.com>,
	intel-wired-lan@...ts.osuosl.org, netdev@...r.kernel.org
Subject: Re: [PATCH iwl-next v2 0/4] igb: XDP/ZC follow up

On Wed, Feb 19, 2025 at 06:06:51PM -0800, Jakub Kicinski wrote:
> On Wed, 19 Feb 2025 08:39:08 +0100 Kurt Kanzenbach wrote:
> > > My comment from the previous series still stands, which simply that
> > > I have no idea if the maintainers will accept changes using this API
> > > or prefer to wait until Stanislav's work [1] is completed to remove
> > > the RTNL requirement from this API altogether.  
> > 
> > I'd rather consider patch #2 a bugfix to restore the busy polling with
> > XDP/ZC. After commit 5ef44b3cb43b ("xsk: Bring back busy polling
> > support") it is a requirement to implement this API.
> > 
> > The maintainers didn't speak up on v1, so i went along and sent v2.
> > 
> > @Jakub: What's your preference? Would you accept this series or rather
> > like to wait for Stanislav's work to be finished?
> 
> No strong preference. If rtnl_lock is not causing any issues 
> in this driver, the we can merge as is. I haven't followed 
> the past discussions, tho.

Don't mean to side-track this thread, but does this mean you've
changed your mind on the previous virtio_net thread [1] ?

Or maybe I'm just misreading your response there? And instead I
could re-spin the virtio_net but dropping the first patch and
dealing with RTNL in the code like this series is doing?

For some reason I was under the impression that the virtio_net
series and others like it (like this igb series) were being held
back until locking work Stanislav is doing is done.

[1]: https://lore.kernel.org/netdev/20250127133756.413efb24@kernel.org/