linux-kernel - Re: [PATCH] x86/irq: Lower unhandled irq error severity

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <69841ea6-5998-46ca-8e49-3e9ee65fc8b1@www.fastmail.com>
Date:   Tue, 01 Dec 2020 10:18:21 +0200
From:   Laurențiu Nicola <lnicola@...d.ro>
To:     "Thomas Gleixner" <tglx@...utronix.de>
Cc:     mingo@...nel.org, bp@...en8.de, x86@...nel.org, trivial@...nel.org,
        LKML <linux-kernel@...r.kernel.org>,
        "Tom Lendacky" <thomas.lendacky@....com>
Subject: Re: [PATCH] x86/irq: Lower unhandled irq error severity

On Tue, Dec 1, 2020, at 01:34, Thomas Gleixner wrote:
> The point is that for some cases this can result in a non working
> machine which just hangs and if it's below the usual loglevel cutoff,
> then it's not visible, which is more annoying than a non-quiet boot if
> you're affected.

For most (desktop) users "errors" will be shown by default, and if anyone is having trouble, they can temporarily remove "quiet" from the kernel command line while debugging it, so it's easy. On the other hand, I don't think it's possible to silence the emergency messages (and I'd still like to see them for any "something is on fire").

The only other use of `pr_emerg_ratelimited` seems to be an informational message shown on non-AMD MCEs ("run mcelog --ascii"). `pr_emerg` is used in more places, but they do sound like critical situations that will bring the system down anyway.

> 
> We are looking into a way to mitigate that AMD wreckage, but so far we
> don't even know where exactly this comes from. The reason why we are
> pretty sure that it is a BIOS/Firmware issue is that some people
> reported it to be gone after a BIOS update and quite some machines do
> not have this issue at all.

In my case, it's latest BIOS version available. Could be AGESA-related, maybe we could install a no-op handler for that IRQ?

> 
> Just for completeness sake. Can you provide the line in /proc/interrupts
> for irq 7 on that machine?

  55:          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0  IR-PCI-MSI 2625543-edge      xhci_hcd

PS: I now see that this was reported a lot of times, including e.g. https://lkml.org/lkml/2019/3/6/97.

Thanks,
Laurențiu