netdev - Re: [PATCH net-next v5 0/2] Introduce auxiliary bus IRQs sysfs

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, 28 May 2024 19:57:22 +0200
From: Greg KH <gregkh@...uxfoundation.org>
To: Shay Drory <shayd@...dia.com>
Cc: netdev@...r.kernel.org, pabeni@...hat.com, davem@...emloft.net,
	kuba@...nel.org, edumazet@...gle.com, david.m.ertman@...el.com,
	rafael@...nel.org, ira.weiny@...el.com, linux-rdma@...r.kernel.org,
	leon@...nel.org, tariqt@...dia.com
Subject: Re: [PATCH net-next v5 0/2] Introduce auxiliary bus IRQs sysfs

On Tue, May 28, 2024 at 12:11:42PM +0300, Shay Drory wrote:
> Today, PCI PFs and VFs, which are anchored on the PCI bus, display their
> IRQ information in the <pci_device>/msi_irqs/<irq_num> sysfs files. PCI
> subfunctions (SFs) are similar to PFs and VFs and these SFs are anchored
> on the auxiliary bus. However, these PCI SFs lack such IRQ information
> on the auxiliary bus, leaving users without visibility into which IRQs
> are used by the SFs. This absence makes it impossible to debug
> situations and to understand the source of interrupts/SFs for
> performance tuning and debug.

Wait, again, this feels wrong.  You should be able to walk back up the
tree see the irq for the device, and vf, right?  Why would the value be
different down in the aux device?  Does the msi irq somehow not actually
show anywhere for the real pci device in sysfs at all today?

What does sysfs look like today exactly for this information?

And what about /proc/irq/ and /proc/interrupts/ doesn't that show you
the needed information?  Why are aux devices somehow "special" here?

> Additionally, the SFs are multifunctional devices supporting RDMA,
> network devices, clocks, and more, similar to their peer PCI PFs and
> VFs. Therefore, it is desirable to have SFs' IRQ information available
> at the bus/device level.

But it should be as part of the pci device, as that's where that
information lives and is "bound" to, not the aux device on its own.

> To overcome the above limitations, this short series extends the
> auxiliary bus to display IRQ information in sysfs, similar to that of
> PFs and VFs.

Again, examples of what it looks like today, and what it will look like
with this patch set is needed in order to justify why this really is
needed as it seems that the information should already be there for you.

> It adds an 'irqs' directory under the auxiliary device and includes an
> <irq_num> sysfs file within it. Sometimes, the PCI SF auxiliary devices
> share the IRQ with other SFs, a detail that is also not available to the
> users. Consequently, this <irq_num> file indicates whether the IRQ is
> 'exclusive' or 'shared'.  This 'irqs' directory extenstion is optional,
> i.e. only for PCI SFs the sysfs irq information is optionally exposed.

Why does userspace care about "shared" or not?  What can they do with
that, and why?

> For example:
> $ ls /sys/bus/auxiliary/devices/mlx5_core.sf.1/irqs/
> 50  51  52  53  54  55  56  57  58
> $ cat /sys/bus/auxiliary/devices/mlx5_core.sf.1/irqs/52
> exclusive

"exclusive" for now, but again, why?  Who cares?  These are msi irqs it
shouldn't matter if they are shared or not.

thanks,

greg k-h