linux-kernel - Re: [PATCH 0/6] genirq/test: Platform/architecture fixes

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: <CABVgOSkfADJGnMekV9Zz4x_Ana2uZYMnca1SDXoJnWjvPRGv8Q@mail.gmail.com>
Date: Thu, 21 Aug 2025 11:45:16 +0800
From: David Gow <davidgow@...gle.com>
To: Brian Norris <briannorris@...omium.org>, Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: Thomas Gleixner <tglx@...utronix.de>, Guenter Roeck <linux@...ck-us.net>, linux-kernel@...r.kernel.org, 
	kunit-dev@...glegroups.com
Subject: Re: [PATCH 0/6] genirq/test: Platform/architecture fixes

On Thu, 21 Aug 2025 at 01:22, Brian Norris <briannorris@...omium.org> wrote:
>
> On Wed, Aug 20, 2025 at 03:00:34PM +0800, David Gow wrote:
> > Looks like __irq_alloc_descs() is returning -ENOMEM (as
> > irq_find_free_area() is returning 200 w/ nr_irqs == 200, and
> > CONFIG_SPARSE_IRQ=n).
>
> Thanks for the insight. I bothered compiling my own qemu just so I can
> run m68k this time, and I can reproduce.
>
> I wonder if I should make everything (CONFIG_IRQ_KUNIT_TEST) depend on
> CONFIG_SPARSE_IRQ, since it seems like arches like m68k can't enable
> SPARSE_IRQ, and they can't allocate new (fake) IRQs without it. That'd
> be a tweak to patch 4.
>
> Or maybe just 'depends on !M68K', since architectures with higher
> NR_IRQS headroom may still work even without SPARSE_IRQ.
>

I'm not an m68k expert (so I've CCed Geert), but I think different
m68k configs do have different NR_IRQS, so it's possible there are
working m68k setups, too. (It also seems slightly suspicious to me
that exactly 200 IRQs are allocated here, though, so a lack of extra
headroom may be deliberate and/or triggered by something trying to
allocate all IRQs.)

Personally, I don't have any m68k machines lying around, so disabling
the test so my qemu scripts don't report errors is fine by me. Ideally
the dependency would be as narrow as possible, but that may well be
!M68K.

The other option would be to try to skip the test if there aren't free
IRQs, but maybe that'd hide real issues?

Regardless, I'll defer to the IRQ and m68k experts here: as long as
I'm not seeing errors, I'm happy. :-)

Cheers,
-- David

Download attachment "smime.p7s" of type "application/pkcs7-signature" (5281 bytes)