From: Vladimir Murzin <vladimir.murzin@arm.com>
To: Jinjie Ruan <ruanjinjie@huawei.com>,
Mark Rutland <mark.rutland@arm.com>,
Breno Leitao <leitao@debian.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
"Peter Zijlstra (Intel)" <peterz@infradead.org>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, bpf@vger.kernel.org,
rmikey@meta.com, kernel-team@meta.com,
Ada Couprie Diaz <ada.coupriediaz@arm.com>
Subject: Re: [PATCH RFC] arm64: entry: PSTATE_I_SET is leaking on pseudo NMI mode
Date: Tue, 11 Aug 2026 09:18:42 +0100 [thread overview]
Message-ID: <e2325b50-882c-4948-ae0c-d84a39e50331@arm.com> (raw)
In-Reply-To: <77080aa8-7df1-43f0-8c82-1096db05f745@huawei.com>
On 8/11/26 03:47, Jinjie Ruan wrote:
>
> 在 2026/8/10 21:04, Vladimir Murzin 写道:
>> On 8/10/26 13:44, Jinjie Ruan wrote:
>>>> Agreed on the need for a clearer explanation.
>>>>
>>>> Perhaps local_irq_disable() isn't the right API here, and we should
>>>> use local_daif_restore(DAIF_PROCCTX_NOIRQ) instead?
>>> The local_irq_disable() here is pair with the local_irq_enable() in
>>> preempt_schedule_irq(). So I think it is not correct to replace them
>>> separately.
>>>
>>> The pseudo NMI does not consider how to do local_irq_disable() /enable()
>>> when the interrupt is masked by the DAIF.I bit as I reported before.
>> Unless I missed anything local_daif_restore(DAIF_PROCCTX_NOIRQ) would
>> clear DAIF.{IF} and set PMR to GIC_PRIO_IRQOFF which is the state we
> Hi, Vladimir,
>
> Yes, local_daif_restore(DAIF_PROCCTX_NOIRQ) does indeed clear the
> DAIF.IF bit and then set the PMR to IRQOFF.
>
> But there is a side effect that will clear the DAIF.{DA} bit. This will
> cause `arch_irqentry_exit_need_resched()` to bypass the DAIF check.
> Originally, it could not be preempted, but after this fix, it becomes
> preemptible.
>
> As the below comment said, If DAIF.{DA} is set, we may be handling an
> NMI or debug context, and preemption should not occur.
>
Yes, indeed, it is why in my other reply I added
"if we believe it is OK to downgrade the inherited context"
... and it seems it is not OK.
Cheers
Vladimir
> 30 static inline bool arch_irqentry_exit_need_resched(void)
> 31 {
> 32 >-------/*
> 33 >------- * DAIF.DA are cleared at the start of IRQ/FIQ handling, and
> when GIC
> 34 >------- * priority masking is used the GIC irqchip driver will
> clear DAIF.IF
> 35 >------- * using gic_arch_enable_irqs() for normal IRQs. If anything
> is set in
> 36 >------- * DAIF we must have handled an NMI, so skip preemption.
> 37 >------- */
> 38 >-------if (system_uses_irq_prio_masking() && read_sysreg(daif))
> 39 >------->-------return false;
>
> Best regards,
> Jinjie
>
>> expect from local_irq_disable() so we can do local_irq_{en,dis}able()
>> later on.
>>
>> Cheers
>> Vladimir
>>
WARNING: multiple messages have this Message-ID (diff)
From: Vladimir Murzin <vladimir.murzin@arm.com>
To: Jinjie Ruan <ruanjinjie@huawei.com>,
Mark Rutland <mark.rutland@arm.com>,
Breno Leitao <leitao@debian.org>
Cc: rmikey@meta.com,
"Peter Zijlstra \(Intel\)" <peterz@infradead.org>,
Catalin Marinas <catalin.marinas@arm.com>,
kernel-team@meta.com, linux-kernel@vger.kernel.org,
bpf@vger.kernel.org, Will Deacon <will@kernel.org>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH RFC] arm64: entry: PSTATE_I_SET is leaking on pseudo NMI mode
Date: Tue, 11 Aug 2026 09:18:42 +0100 [thread overview]
Message-ID: <e2325b50-882c-4948-ae0c-d84a39e50331@arm.com> (raw)
In-Reply-To: <77080aa8-7df1-43f0-8c82-1096db05f745@huawei.com>
On 8/11/26 03:47, Jinjie Ruan wrote:
>
> 在 2026/8/10 21:04, Vladimir Murzin 写道:
>> On 8/10/26 13:44, Jinjie Ruan wrote:
>>>> Agreed on the need for a clearer explanation.
>>>>
>>>> Perhaps local_irq_disable() isn't the right API here, and we should
>>>> use local_daif_restore(DAIF_PROCCTX_NOIRQ) instead?
>>> The local_irq_disable() here is pair with the local_irq_enable() in
>>> preempt_schedule_irq(). So I think it is not correct to replace them
>>> separately.
>>>
>>> The pseudo NMI does not consider how to do local_irq_disable() /enable()
>>> when the interrupt is masked by the DAIF.I bit as I reported before.
>> Unless I missed anything local_daif_restore(DAIF_PROCCTX_NOIRQ) would
>> clear DAIF.{IF} and set PMR to GIC_PRIO_IRQOFF which is the state we
> Hi, Vladimir,
>
> Yes, local_daif_restore(DAIF_PROCCTX_NOIRQ) does indeed clear the
> DAIF.IF bit and then set the PMR to IRQOFF.
>
> But there is a side effect that will clear the DAIF.{DA} bit. This will
> cause `arch_irqentry_exit_need_resched()` to bypass the DAIF check.
> Originally, it could not be preempted, but after this fix, it becomes
> preemptible.
>
> As the below comment said, If DAIF.{DA} is set, we may be handling an
> NMI or debug context, and preemption should not occur.
>
Yes, indeed, it is why in my other reply I added
"if we believe it is OK to downgrade the inherited context"
... and it seems it is not OK.
Cheers
Vladimir
> 30 static inline bool arch_irqentry_exit_need_resched(void)
> 31 {
> 32 >-------/*
> 33 >------- * DAIF.DA are cleared at the start of IRQ/FIQ handling, and
> when GIC
> 34 >------- * priority masking is used the GIC irqchip driver will
> clear DAIF.IF
> 35 >------- * using gic_arch_enable_irqs() for normal IRQs. If anything
> is set in
> 36 >------- * DAIF we must have handled an NMI, so skip preemption.
> 37 >------- */
> 38 >-------if (system_uses_irq_prio_masking() && read_sysreg(daif))
> 39 >------->-------return false;
>
> Best regards,
> Jinjie
>
>> expect from local_irq_disable() so we can do local_irq_{en,dis}able()
>> later on.
>>
>> Cheers
>> Vladimir
>>
next prev parent reply other threads:[~2026-08-11 8:18 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-07 11:45 [PATCH RFC] arm64: entry: PSTATE_I_SET is leaking on pseudo NMI mode Breno Leitao
2026-08-07 13:40 ` Will Deacon
2026-08-07 13:40 ` Will Deacon
2026-08-07 13:57 ` Mark Rutland
2026-08-07 13:57 ` Mark Rutland
2026-08-07 14:49 ` Vladimir Murzin
2026-08-07 14:49 ` Vladimir Murzin
2026-08-10 12:44 ` Jinjie Ruan
2026-08-10 12:44 ` Jinjie Ruan
2026-08-10 13:04 ` Vladimir Murzin
2026-08-10 13:04 ` Vladimir Murzin
2026-08-11 2:47 ` Jinjie Ruan
2026-08-11 2:47 ` Jinjie Ruan
2026-08-11 8:18 ` Vladimir Murzin [this message]
2026-08-11 8:18 ` Vladimir Murzin
2026-08-07 14:58 ` Breno Leitao
2026-08-07 14:58 ` Breno Leitao
2026-08-07 16:29 ` Breno Leitao
2026-08-07 16:29 ` Breno Leitao
2026-08-10 11:43 ` Will Deacon
2026-08-10 11:43 ` Will Deacon
2026-08-10 12:42 ` Vladimir Murzin
2026-08-10 12:42 ` Vladimir Murzin
2026-08-10 15:05 ` Will Deacon
2026-08-10 15:05 ` Will Deacon
2026-08-10 16:39 ` Vladimir Murzin
2026-08-10 16:39 ` Vladimir Murzin
2026-08-10 12:51 ` Jinjie Ruan
2026-08-10 12:51 ` Jinjie Ruan
2026-08-10 12:59 ` Breno Leitao
2026-08-10 12:59 ` Breno Leitao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e2325b50-882c-4948-ae0c-d84a39e50331@arm.com \
--to=vladimir.murzin@arm.com \
--cc=ada.coupriediaz@arm.com \
--cc=bpf@vger.kernel.org \
--cc=catalin.marinas@arm.com \
--cc=kernel-team@meta.com \
--cc=leitao@debian.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=peterz@infradead.org \
--cc=rmikey@meta.com \
--cc=ruanjinjie@huawei.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.