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 17:47:15 +0200
From: Przemek Kitszel <przemyslaw.kitszel@...el.com>
To: Shay Drory <shayd@...dia.com>
CC: <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>, <gregkh@...uxfoundation.org>,
	<david.m.ertman@...el.com>
Subject: Re: [PATCH net-next v7 1/2] driver core: auxiliary bus: show
 auxiliary device IRQs

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

>   };

[...]