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]
Date:   Fri, 14 Oct 2022 12:00:31 -0700
From:   "Bhatnagar, Rishabh" <risbhat@...zon.com>
To:     "Herrenschmidt, Benjamin" <benh@...zon.com>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>
CC:     "sashal@...nel.org" <sashal@...nel.org>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "stable@...r.kernel.org" <stable@...r.kernel.org>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Bacco, Mike" <mbacco@...zon.com>
Subject: Re: [PATCH 0/6] IRQ handling patches backport to 4.14 stable


On 10/9/22 10:50 AM, Bhatnagar, Rishabh wrote:
>
> On 10/6/22 8:07 PM, Herrenschmidt, Benjamin wrote:
>> (putting my @amazon.com hat on)
>>
>> On Sun, 2022-10-02 at 17:30 +0200, Greg KH wrote:
>>
>>
>>> 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?
>> Right. Rishabh answered that separately.
>>
>>>> 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?
>> These were tested on a collection of EC2 instances, virtual and metal I
>> believe (Rishabh, please confirm).
> Yes these patches were tested on multiple virt/metal EC2 instances.
>>
>> Amazon Linux 2 runs 4.14 or 5.10. Unfortunately we still have to
>> support customers running the former.
>>
>> We'll be including these patches in our releases, we thought it would
>> be nice to have them in -stable as well for the sake of whoever else
>> might be still using this kernel. No huge deal if they don't.
>>
>> As for testing -rc's, yes, we need to get better at that (and publish
>> what we test). Point taken :-)
>>
>> Cheers,
>> Ben.
>>
Hi Greg

Let us know if you think it would be beneficial to take these backports 
for 4.14 stable.
We can drop this patch set otherwise.

Thanks alot,
Rishabh

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ