linux-kernel - Re: [PATCH 0/6] IRQ handling patches backport to 4.14 stable

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]

Date:   Sun, 2 Oct 2022 17:30:20 +0200
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Rishabh Bhatnagar <risbhat@...zon.com>
Cc:     stable@...r.kernel.org, sashal@...nel.org, tglx@...utronix.de,
        mingo@...hat.com, linux-kernel@...r.kernel.org, benh@...zon.com,
        mbacco@...zon.com
Subject: Re: [PATCH 0/6] IRQ handling patches backport to 4.14 stable

On Thu, Sep 29, 2022 at 09:06:45PM +0000, Rishabh Bhatnagar wrote:
> This patch series backports a bunch of patches related IRQ handling
> with respect to freeing the irq line while IRQ is in flight at CPU
> or at the hardware level.
> Recently we saw this issue in serial 8250 driver where the IRQ was being
> freed while the irq was in flight or not yet delivered to the CPU. As a
> result the irqchip was going into a wedged state and IRQ was not getting
> delivered to the cpu. These patches helped fixed the issue in 4.14
> kernel.

Why is the serial driver freeing an irq while the system is running?
Ah, this could happen on a tty hangup, right?

> Let us know if more patches need backporting.

What hardware platform were these patches tested on to verify they work
properly?  And why can't they move to 4.19 or newer if they really need
this fix?  What's preventing that?

As Amazon doesn't seem to be testing 4.14.y -rc releases, I find it odd
that you all did this backport.  Is this a kernel that you all care
about?

thanks,

greg k-h