linux-kernel - Re: [patch 01/15] x86/ioapic: Handle allocation failures gracefully

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: <ZrDLTtN2kiPtpY1l@gmail.com>
Date: Mon, 5 Aug 2024 05:53:34 -0700
From: Breno Leitao <leitao@...ian.org>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: LKML <linux-kernel@...r.kernel.org>, x86@...nel.org
Subject: Re: [patch 01/15] x86/ioapic: Handle allocation failures gracefully

On Fri, Aug 02, 2024 at 06:15:34PM +0200, Thomas Gleixner wrote:
> Breno observed panics when using failslab under certain conditions during
> runtime:
> 
>    can not alloc irq_pin_list (-1,0,20)
>    Kernel panic - not syncing: IO-APIC: failed to add irq-pin. Can not proceed
> 
>    panic+0x4e9/0x590
>    mp_irqdomain_alloc+0x9ab/0xa80
>    irq_domain_alloc_irqs_locked+0x25d/0x8d0
>    __irq_domain_alloc_irqs+0x80/0x110
>    mp_map_pin_to_irq+0x645/0x890
>    acpi_register_gsi_ioapic+0xe6/0x150
>    hpet_open+0x313/0x480
> 
> That's a pointless panic which is a leftover of the historic IO/APIC code
> which panic'ed during early boot when the interrupt allocation failed.
> 
> The only place which might justify panic is the PIT/HPET timer_check() code
> which tries to figure out whether the timer interrupt is delivered through
> the IO/APIC. But that code does not require to handle interrupt allocation
> failures. If the interrupt cannot be allocated then timer delivery fails
> and it either panics due to that or falls back to legacy mode.
> 
> Cure this by removing the panic wrapper around __add_pin_to_irq_node() and
> making mp_irqdomain_alloc() aware of the failure condition and handle it as
> any other failure in this function gracefully.
> 
> Reported-by: Breno Leitao <leitao@...ian.org>
> Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
> Link: https://lore.kernel.org/all/ZqfJmUF8sXIyuSHN@gmail.com

Tested-by: Breno Leitao <leitao@...ian.org>

Thanks Thomas!

--breno