linux-kernel - Re: [PATCH 05/12] genirq: Shutdown irq chips in suspend/resume during hibernation

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: <0471e6e3-b6ed-d2c6-db41-1688a0af9abd@oracle.com>
Date:   Sat, 30 May 2020 19:17:41 -0400
From:   Boris Ostrovsky <boris.ostrovsky@...cle.com>
To:     Anchal Agarwal <anchalag@...zon.com>, tglx@...utronix.de,
        mingo@...hat.com, bp@...en8.de, hpa@...or.com, x86@...nel.org,
        jgross@...e.com, linux-pm@...r.kernel.org, linux-mm@...ck.org,
        kamatam@...zon.com, sstabellini@...nel.org, konrad.wilk@...cle.com,
        roger.pau@...rix.com, axboe@...nel.dk, davem@...emloft.net,
        rjw@...ysocki.net, len.brown@...el.com, pavel@....cz,
        peterz@...radead.org, eduval@...zon.com, sblbir@...zon.com,
        xen-devel@...ts.xenproject.org, vkuznets@...hat.com,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        dwmw@...zon.co.uk, benh@...nel.crashing.org
Subject: Re: [PATCH 05/12] genirq: Shutdown irq chips in suspend/resume during
 hibernation

On 5/19/20 7:26 PM, Anchal Agarwal wrote:
> Many legacy device drivers do not implement power management (PM)
> functions which means that interrupts requested by these drivers stay
> in active state when the kernel is hibernated.
>
> This does not matter on bare metal and on most hypervisors because the
> interrupt is restored on resume without any noticable side effects as
> it stays connected to the same physical or virtual interrupt line.
>
> The XEN interrupt mechanism is different as it maintains a mapping
> between the Linux interrupt number and a XEN event channel. If the
> interrupt stays active on hibernation this mapping is preserved but
> there is unfortunately no guarantee that on resume the same event
> channels are reassigned to these devices. This can result in event
> channel conflicts which prevent the affected devices from being
> restored correctly.
>
> One way to solve this would be to add the necessary power management
> functions to all affected legacy device drivers, but that's a
> questionable effort which does not provide any benefits on non-XEN
> environments.
>
> The least intrusive and most efficient solution is to provide a
> mechanism which allows the core interrupt code to tear down these
> interrupts on hibernation and bring them back up again on resume. This
> allows the XEN event channel mechanism to assign an arbitrary event
> channel on resume without affecting the functionality of these
> devices.
>
> Fortunately all these device interrupts are handled by a dedicated XEN
> interrupt chip so the chip can be marked that all interrupts connected
> to it are handled this way. This is pretty much in line with the other
> interrupt chip specific quirks, e.g. IRQCHIP_MASK_ON_SUSPEND.
>
> Add a new quirk flag IRQCHIP_SHUTDOWN_ON_SUSPEND and add support for
> it the core interrupt suspend/resume paths.
>
> Signed-off-by: Anchal Agarwal <anchalag@...zon.com>
> Signed-off--by: Thomas Gleixner <tglx@...utronix.de>


Since Thomas wrote this patch I think it should also have "From: " him.


-boris