linux-kernel - Re: [RFC v2] x86: Select HARDIRQS_SW

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: <87a74mk0gm.fsf@nanos.tec.linutronix.de>
Date:   Wed, 11 Mar 2020 23:09:45 +0100
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Hans de Goede <hdegoede@...hat.com>,
        Mika Westerberg <mika.westerberg@...ux.intel.com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        "H . Peter Anvin" <hpa@...or.com>
Cc:     linux-gpio@...r.kernel.org, linux-acpi@...r.kernel.org,
        x86@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC v2] x86: Select HARDIRQS_SW_RESEND on x86

Hans de Goede <hdegoede@...hat.com> writes:
> On 3/11/20 10:31 PM, Thomas Gleixner wrote:
>> Hans de Goede <hdegoede@...hat.com> writes:
>>>> I just need to stare at the legacy PIC and the virt stuff.
>>>>
>>>>> Also maybe we should add a Cc: stable@...r.kernel.org ??? This seems like
>>>>> somewhat a big change for that but it does solve some real issues...
>>>>
>>>> Yes. Let me stare at the couple of weird irqchips which might get
>>>> surprised. I'll teach them not to do that :)
>>>
>>> I know that you are very busy, still I'm wondering is there any progress
>>> on this ?
>> 
>> Bah. That fell through the cracks, but actually I looked at this due to
>> the PCI-E AER wreckage. So yes, this is fine, but we want:
>> 
>>   https://lkml.kernel.org/r/20200306130623.590923677@linutronix.de
>>   https://lkml.kernel.org/r/20200306130623.684591280@linutronix.de
>> 
>> if we want to backport this to stable.
>
> So far I have seen a few, but not a lot of devices which need this, so
> I'm not 100% sure what to do here.
>
> Do you consider this change safe / suitable for stable if those 2 patches
> are backported and applied first?

I think so. The two patches are on my list for backports anyway, but I
wanted to give them some time to simmer.

Thanks,

        tglx