linux-kernel - Re: How to know if there is a pending interrupt when they are masked?

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: <3a4ca5d5-9b90-e4e0-84ab-420bf5e460db@arm.com>
Date:   Thu, 14 Feb 2019 15:47:31 +0000
From:   Marc Zyngier <marc.zyngier@....com>
To:     Thomas Gleixner <tglx@...utronix.de>,
        Daniel Lezcano <daniel.lezcano@...aro.org>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>
Subject: Re: How to know if there is a pending interrupt when they are masked?

On 14/02/2019 15:35, Thomas Gleixner wrote:
> On Thu, 14 Feb 2019, Daniel Lezcano wrote:
>> today we have the possibility to mask the local interrupt with the
>> command local_irq_disable / local_irq_enable.
>>
>> The power management path disables the local interrupt in order to
>> initiate a power down sequence. If there is a pending interrupt this one
>> will make the power down function to abort, thus exiting right after
>> calling the shutdown function after costly operations. It could be
>> interesting to check if there is a pending interrupt before initiating
>> the power down sequence.
>>
>> Is there a way to know if there is a pending interrupt on the current
>> CPU when the local interrupt are disabled? Something like,
>> local_irq_pending() function ?
> 
> We have nothing like that today, but it would be possible to implement this
> at least on x86 by peeking the local APIC registers.

On arm64, reading ISR_EL1 would give some indication of that, but...

> OTOH, the question is whether it's worth the trouble because the interrupt
> could come in right after the query and the same issue which you want to
> address persists. It only makes sense if it reduces the time window so
> significantly that it actually matters.

as Thomas explains, the potential race is pretty tight.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...