linux-kernel - Re: [PATCH 1/1] selftest: drivers: Add support its msi hwirq checking

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] [day] [month] [year] [list]

Message-ID: <87ikwl40mm.ffs@tglx>
Date: Thu, 01 Aug 2024 01:12:17 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Bjorn Helgaas <helgaas@...nel.org>, Joseph Jang <jjang@...dia.com>
Cc: shuah@...nel.org, mochs@...dia.com, linux-kernel@...r.kernel.org,
 linux-kselftest@...r.kernel.org, linux-tegra@...r.kernel.org
Subject: Re: [PATCH 1/1] selftest: drivers: Add support its msi hwirq checking

On Wed, Jul 31 2024 at 22:42, Thomas Gleixner wrote:
> Aside of that the proposed parser does not even work anymore on 6.11
> because we switched ARM[64] over to per device domains during the merge
> window.
>
> So if we want a selftest for the correctness of the hardware interrupt
> numbers then it should grab the per interrupt sysfs entry 'chip_name'
> and 'hwirq' pairs and do an analysis per 'chip_name' whether all
> hardware interrupt numbers for a chip are unique.

I just hacked up a 20 lines snake script to analyze it and indeed that
produces duplicates because some interrupt chips do not have unique chip
names as they are shared between interrupt domains and the chip names
are constant.

There are several ways to handle this:

  1) Amend /sys/kernel/irq/$N/chip_name with the irq domain name

  2) Expose the irq domain name in /sys/kernel/irq/$N/domain_name

  3) Utilize the existing /sys/kernel/debug/irq/ mechanism

#1 Does change the output of chip_name, but that is a kernel internal
   detail anyway so there is no real UABI concern.

#2 has the advantage that it does not change the output of chip_name but
   it consumes more memory for a dubious value.

#3 has the downside that it requires CONFIG_GENERIC_IRQ_DEBUGFS=y and is
   root only, but that should be not a problem for testing. We have other
   selftests which have Kconfig dependencies and root requirements. The
   upside is that it does not require kernel changes.

No real strong opinion either way, but all of that is better than a ITS
specific parser which fails to work on the next kernel version.

Thanks,

        tglx