netdev - Re: [PATCH iwl-next 05/14] libeth: add control queue support

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: <20250410112349.GP199604@unreal>
Date: Thu, 10 Apr 2025 14:23:49 +0300
From: Leon Romanovsky <leon@...nel.org>
To: Larysa Zaremba <larysa.zaremba@...el.com>
Cc: intel-wired-lan@...ts.osuosl.org,
	Tony Nguyen <anthony.l.nguyen@...el.com>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Simon Horman <horms@...nel.org>, Jonathan Corbet <corbet@....net>,
	Przemek Kitszel <przemyslaw.kitszel@...el.com>,
	Jiri Pirko <jiri@...nulli.us>,
	Tatyana Nikolova <tatyana.e.nikolova@...el.com>,
	Andrew Lunn <andrew+netdev@...n.ch>,
	Alexander Lobakin <aleksander.lobakin@...el.com>,
	Michael Ellerman <mpe@...erman.id.au>,
	Maciej Fijalkowski <maciej.fijalkowski@...el.com>,
	Lee Trager <lee@...ger.us>,
	Madhavan Srinivasan <maddy@...ux.ibm.com>,
	Sridhar Samudrala <sridhar.samudrala@...el.com>,
	Jacob Keller <jacob.e.keller@...el.com>,
	Michal Swiatkowski <michal.swiatkowski@...ux.intel.com>,
	Mateusz Polchlopek <mateusz.polchlopek@...el.com>,
	Ahmed Zaki <ahmed.zaki@...el.com>, netdev@...r.kernel.org,
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
	"Karlsson, Magnus" <magnus.karlsson@...el.com>,
	Emil Tantilov <emil.s.tantilov@...el.com>,
	Madhu Chittim <madhu.chittim@...el.com>,
	Josh Hay <joshua.a.hay@...el.com>,
	Milena Olech <milena.olech@...el.com>, pavan.kumar.linga@...el.com,
	"Singhai, Anjali" <anjali.singhai@...el.com>,
	Phani R Burra <phani.r.burra@...el.com>
Subject: Re: [PATCH iwl-next 05/14] libeth: add control queue support

On Thu, Apr 10, 2025 at 12:44:33PM +0200, Larysa Zaremba wrote:
> On Thu, Apr 10, 2025 at 11:21:37AM +0300, Leon Romanovsky wrote:
> > On Tue, Apr 08, 2025 at 02:47:51PM +0200, Larysa Zaremba wrote:
> > > From: Phani R Burra <phani.r.burra@...el.com>
> > > 
> > > Libeth will now support control queue setup and configuration APIs.
> > > These are mainly used for mailbox communication between drivers and
> > > control plane.
> > > 
> > > Make use of the page pool support for managing controlq buffers.
> > 
> > <...>
> > 
> > >  libeth-y			:= rx.o
> > >  
> > > +obj-$(CONFIG_LIBETH_CP)		+= libeth_cp.o
> > > +
> > > +libeth_cp-y			:= controlq.o
> > 
> > So why did you create separate module for it?
> > Now you have pci -> libeth -> libeth_cp -> ixd, with the potential races between ixd and libeth, am I right?
> >
> 
> I am not sure what kind of races do you mean, all libeth modules themselves are 
> stateless and will stay this way [0], all used data is owned by drivers.

Somehow such separation doesn't truly work. There are multiple syzkaller
reports per-cycle where module A tries to access module C, which already
doesn't exist because it was proxied through module B.

> 
> As for the module separation, I think there is no harm in keeping it modular. 

Syzkaller reports disagree with you. 

> We intend to use basic libeth (libeth_rx) in drivers that for sure have no use 
> for libeth_cp. libeth_pci and libeth_cp separation is more arbitral, as we have 
> no plans for now to use them separately.

So let's not over-engineer it.

> 
> Module dependencies are as follows:
> 
> libeth_rx and libeth_pci do not depend on other modules.
> libeth_cp depends on both libeth_rx and libeth_pci.
> idpf directly uses libeth_pci, libeth_rx and libeth_cp.
> ixd directly uses libeth_cp and libeth_pci.

You can do whatever module architecture for netdev devices, but if you
plan to expose it to RDMA devices, I will vote against any deep layered
module architecture for the drivers.

BTW, please add some Intel prefix to the modules names, they shouldn't
be called in generic names like libeth, e.t.c

Thanks

> 
> [0] https://lore.kernel.org/netdev/61bfa880-6a88-4eac-bab7-040bf72a11ef@intel.com/
> 
> > Thanks