public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@kernel.org>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
	linux-arm-kernel@lists.infradead.org, ada.coupriediaz@arm.com,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	luto@kernel.org, ruanjinjie@huawei.com, vladimir.murzin@arm.com,
	will@kernel.org
Subject: Re: [PATCH 1/2] arm64/entry: Fix involuntary preemption exception masking
Date: Fri, 20 Mar 2026 16:50:03 +0100	[thread overview]
Message-ID: <875x6qjyac.ffs@tglx> (raw)
In-Reply-To: <ab1gYcG_-EFNKALm@J2N7QTR9R3.cambridge.arm.com>

On Fri, Mar 20 2026 at 14:57, Mark Rutland wrote:
> On Fri, Mar 20, 2026 at 03:11:20PM +0100, Thomas Gleixner wrote:
>> Yes. It's not an optimization. It's a correctness issue.
>> 
>> If the interrupted context is RCU idle then you have to carefully go
>> back to that context. So that the context can tell RCU it is done with
>> the idle state and RCU has to pay attention again. Otherwise all of this
>> becomes imbalanced.
>> 
>> This is about context-level nesting:
>> 
>>         ...
>> L1.A    ct_cpuidle_enter();
>> 
>>                         -> interrupt
>>  L2.A                           ct_irq_enter();
>>                                 ...             // Set NEED_RESCHED
>>  L2.B                           ct_irq_exit();
>>                                
>>         ...
>> L1.B    ct_cpuidle_exit();
>> 
>> Scheduling between #L2.B and #L1.B makes RCU rightfully upset. 
>
> I suspect I'm missing something obvious here:
>
> * Regardless of nesting, I see that scheduling between L2.B and L1.B is
>   broken because RCU isn't watching.
>
> * I'm not sure whether there's a problem with scheduling between L2.A
>   and L2.B, which is what arm64 used to do, and what arm64 would do
>   after this patch.

The only reason why it "works" is that the idle task has preemption
permanently disabled, so it won't really schedule even if need_resched()
is set. So it "works" by chance and not by design.

Apply the patch below and watch the show.

> Thanks for all of this. Even if I'm confused right now, it's very
> helpful!

RCU induced confusion is perfectly normal. Everyone suffers from that at
some point. Welcome to the club.

Thanks,

        tglx
---
--- a/kernel/entry/common.c
+++ b/kernel/entry/common.c
@@ -187,9 +187,10 @@ static inline bool arch_irqentry_exit_ne
 
 void raw_irqentry_exit_cond_resched(void)
 {
+	rcu_irq_exit_check_preempt();
+
 	if (!preempt_count()) {
 		/* Sanity check RCU and thread stack */
-		rcu_irq_exit_check_preempt();
 		if (IS_ENABLED(CONFIG_DEBUG_ENTRY))
 			WARN_ON_ONCE(!on_thread_stack());
 		if (need_resched() && arch_irqentry_exit_need_resched())



  parent reply	other threads:[~2026-03-20 15:50 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-20 11:30 [PATCH 0/2] arm64/entry: Fix involuntary preemption exception masking Mark Rutland
2026-03-20 11:30 ` [PATCH 1/2] " Mark Rutland
2026-03-20 13:04   ` Peter Zijlstra
2026-03-20 14:11     ` Thomas Gleixner
2026-03-20 14:57       ` Mark Rutland
2026-03-20 15:34         ` Peter Zijlstra
2026-03-20 16:16           ` Mark Rutland
2026-03-20 15:50         ` Thomas Gleixner [this message]
2026-03-23 17:21           ` Mark Rutland
2026-03-20 14:59   ` Thomas Gleixner
2026-03-20 15:37     ` Mark Rutland
2026-03-20 16:26       ` Thomas Gleixner
2026-03-20 17:31         ` Mark Rutland
2026-03-21 23:25           ` Thomas Gleixner
2026-03-24 12:19             ` Thomas Gleixner
2026-03-25 11:03             ` Mark Rutland
2026-03-25 15:46               ` Thomas Gleixner
2026-03-26  8:56                 ` Jinjie Ruan
2026-03-26 18:11                 ` Mark Rutland
2026-03-26 18:32                   ` Thomas Gleixner
2026-03-27  1:27                   ` Jinjie Ruan
2026-03-26  8:52               ` Jinjie Ruan
2026-03-24  3:14   ` Jinjie Ruan
2026-03-24 10:51     ` Mark Rutland
2026-03-20 11:30 ` [PATCH 2/2] arm64/entry: Remove arch_irqentry_exit_need_resched() Mark Rutland

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=875x6qjyac.ffs@tglx \
    --to=tglx@kernel.org \
    --cc=ada.coupriediaz@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=peterz@infradead.org \
    --cc=ruanjinjie@huawei.com \
    --cc=vladimir.murzin@arm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox