netdev - Re: [PATCH net-next v7 1/2] driver core: auxiliary bus: show auxiliary device IRQs

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]

Date: Tue, 18 Jun 2024 18:08:06 +0200
From: Greg KH <gregkh@...uxfoundation.org>
To: Przemek Kitszel <przemyslaw.kitszel@...el.com>
Cc: Shay Drory <shayd@...dia.com>, rafael@...nel.org, ira.weiny@...el.com,
	netdev@...r.kernel.org, linux-rdma@...r.kernel.org, leon@...nel.org,
	tariqt@...dia.com, Parav Pandit <parav@...dia.com>,
	pabeni@...hat.com, davem@...emloft.net, kuba@...nel.org,
	edumazet@...gle.com, david.m.ertman@...el.com
Subject: Re: [PATCH net-next v7 1/2] driver core: auxiliary bus: show
 auxiliary device IRQs

On Tue, Jun 18, 2024 at 05:47:15PM +0200, Przemek Kitszel wrote:
> On 6/18/24 17:09, Shay Drory wrote:
> > PCI subfunctions (SF) are anchored on the auxiliary bus. PCI physical
> > and virtual functions are anchored on the PCI bus. The irq information
> > of each such function is visible to users via sysfs directory "msi_irqs"
> > containing files for each irq entry. However, for PCI SFs such
> > information is unavailable. Due to this users have no visibility on IRQs
> > used by the SFs.
> > Secondly, an SF can be multi function device supporting rdma, netdevice
> > and more. Without irq information at the bus level, the user is unable
> > to view or use the affinity of the SF IRQs.
> > 
> > Hence to match to the equivalent PCI PFs and VFs, add "irqs" directory,
> > for supporting auxiliary devices, containing file for each irq entry.
> > 
> > For example:
> > $ ls /sys/bus/auxiliary/devices/mlx5_core.sf.1/irqs/
> > 50  51  52  53  54  55  56  57  58
> > 
> > Reviewed-by: Parav Pandit <parav@...dia.com>
> > Signed-off-by: Shay Drory <shayd@...dia.com>
> > 
> > ---
> > v6-v7:
> > - dynamically creating irqs directory when first irq file created (Greg)
> > - removed irqs flag and simplified the dev_add() API (Greg)
> > - move sysfs related new code to a new auxiliary_sysfs.c file (Greg)
> 
> [...]
> 
> > +static int auxiliary_irq_dir_prepare(struct auxiliary_device *auxdev)
> > +{
> > +	int ret = 0;
> > +
> > +	mutex_lock(&auxdev->lock);
> > +	if (auxdev->dir_exists)
> > +		goto unlock;
> > +
> > +	xa_init(&auxdev->irqs);
> 
> due to below error handling you could end up with calling xa_init()
> twice (and this is a "library" code, so it does not matter how you
> handle this error in the current sole user ;))
> 
> > +	ret = devm_device_add_group(&auxdev->dev, &auxiliary_irqs_group);
> > +	if (!ret)
> > +		auxdev->dir_exists = 1;
> > +
> > +unlock:
> > +	mutex_unlock(&auxdev->lock);
> > +	return ret;
> > +}
> > +
> 
> [...]
> 
> > --- a/include/linux/auxiliary_bus.h
> > +++ b/include/linux/auxiliary_bus.h
> > @@ -58,6 +58,7 @@
> >    *       in
> >    * @name: Match name found by the auxiliary device driver,
> >    * @id: unique identitier if multiple devices of the same name are exported,
> > + * @irqs: irqs xarray contains irq indices which are used by the device,
> >    *
> >    * An auxiliary_device represents a part of its parent device's functionality.
> >    * It is given a name that, combined with the registering drivers
> > @@ -138,7 +139,10 @@
> >   struct auxiliary_device {
> >   	struct device dev;
> >   	const char *name;
> > +	struct xarray irqs;
> > +	struct mutex lock; /* Protects "irqs" directory creation */
> >   	u32 id;
> > +	u8 dir_exists:1;
> 
> nit: I would make it a bool, or `bool: 1` if you really want

Why is this even needed?  It should "know" if the directory is there or
not, it can always be looked up, right?

thanks,

greg k-h