From: Peter Zijlstra <peterz@infradead.org>
To: Valentin Schneider <valentin.schneider@arm.com>
Cc: linux-kernel@vger.kernel.org, linux-rt-users@vger.kernel.org,
rostedt@goodmis.org, mhiramat@kernel.org, bristot@redhat.com,
jbaron@akamai.com, torvalds@linux-foundation.org,
tglx@linutronix.de, mingo@kernel.org, namit@vmware.com,
hpa@zytor.com, luto@kernel.org, ard.biesheuvel@linaro.org,
jpoimboe@redhat.com, pbonzini@redhat.com,
mathieu.desnoyers@efficios.com, linux@rasmusvillemoes.dk,
"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Alex Shi <alex.shi@linaro.org>,
Daniel Lezcano <daniel.lezcano@linaro.org>,
Vincenzo Frascino <Vincenzo.Frascino@arm.com>
Subject: Re: [PATCH] notifier: Make atomic_notifiers use raw_spinlock
Date: Mon, 23 Nov 2020 15:14:16 +0100 [thread overview]
Message-ID: <20201123141416.GO3021@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20201122201904.30940-1-valentin.schneider@arm.com>
On Sun, Nov 22, 2020 at 08:19:04PM +0000, Valentin Schneider wrote:
> Booting a recent PREEMPT_RT kernel (v5.10-rc3-rt7-rebase) on my arm64 Juno
> leads to the idle task blocking on an RT sleeping spinlock down some
> notifier path:
>
> [ 1.809101] BUG: scheduling while atomic: swapper/5/0/0x00000002
> [ 1.809116] Modules linked in:
> [ 1.809123] Preemption disabled at:
> [ 1.809125] secondary_start_kernel (arch/arm64/kernel/smp.c:227)
> [ 1.809146] CPU: 5 PID: 0 Comm: swapper/5 Tainted: G W 5.10.0-rc3-rt7 #168
> [ 1.809153] Hardware name: ARM Juno development board (r0) (DT)
> [ 1.809158] Call trace:
> [ 1.809160] dump_backtrace (arch/arm64/kernel/stacktrace.c:100 (discriminator 1))
> [ 1.809170] show_stack (arch/arm64/kernel/stacktrace.c:198)
> [ 1.809178] dump_stack (lib/dump_stack.c:122)
> [ 1.809188] __schedule_bug (kernel/sched/core.c:4886)
> [ 1.809197] __schedule (./arch/arm64/include/asm/preempt.h:18 kernel/sched/core.c:4913 kernel/sched/core.c:5040)
> [ 1.809204] preempt_schedule_lock (kernel/sched/core.c:5365 (discriminator 1))
> [ 1.809210] rt_spin_lock_slowlock_locked (kernel/locking/rtmutex.c:1072)
> [ 1.809217] rt_spin_lock_slowlock (kernel/locking/rtmutex.c:1110)
> [ 1.809224] rt_spin_lock (./include/linux/rcupdate.h:647 kernel/locking/rtmutex.c:1139)
> [ 1.809231] atomic_notifier_call_chain_robust (kernel/notifier.c:71 kernel/notifier.c:118 kernel/notifier.c:186)
> [ 1.809240] cpu_pm_enter (kernel/cpu_pm.c:39 kernel/cpu_pm.c:93)
> [ 1.809249] psci_enter_idle_state (drivers/cpuidle/cpuidle-psci.c:52 drivers/cpuidle/cpuidle-psci.c:129)
> [ 1.809258] cpuidle_enter_state (drivers/cpuidle/cpuidle.c:238)
> [ 1.809267] cpuidle_enter (drivers/cpuidle/cpuidle.c:353)
> [ 1.809275] do_idle (kernel/sched/idle.c:132 kernel/sched/idle.c:213 kernel/sched/idle.c:273)
> [ 1.809282] cpu_startup_entry (kernel/sched/idle.c:368 (discriminator 1))
> [ 1.809288] secondary_start_kernel (arch/arm64/kernel/smp.c:273)
>
> Two points worth noting:
>
> 1) That this is conceptually the same issue as pointed out in:
> 313c8c16ee62 ("PM / CPU: replace raw_notifier with atomic_notifier")
> 2) Only the _robust() variant of atomic_notifier callchains suffer from
> this
>
> AFAICT only the cpu_pm_notifier_chain really needs to be changed, but
> singling it out would mean introducing a new (truly) non-blocking API. At
> the same time, callers that are fine with any blocking within the call
> chain should use blocking notifiers, so patching up all atomic_notifier's
> doesn't seem *too* crazy to me.
How long are these notifier chains?, and all this pcs_enter_idle_state()
is still horribly broken vs RCU, witness the RCU_NONIDLE() there and the
rcu_irq_enter_irqson() in the pm_notifier code.
That said, we're running these notifiers from the idle path with IRQs
disabled, so taking that spinlock isn't going to make it worse..
next prev parent reply other threads:[~2020-11-23 14:15 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-22 20:19 [PATCH] notifier: Make atomic_notifiers use raw_spinlock Valentin Schneider
2020-11-23 14:14 ` Peter Zijlstra [this message]
2020-11-23 14:52 ` Valentin Schneider
2020-11-30 10:09 ` Valentin Schneider
2020-11-30 13:51 ` Sebastian Andrzej Siewior
2020-11-30 13:55 ` Daniel Bristot de Oliveira
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=20201123141416.GO3021@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=Vincenzo.Frascino@arm.com \
--cc=alex.shi@linaro.org \
--cc=ard.biesheuvel@linaro.org \
--cc=bigeasy@linutronix.de \
--cc=bristot@redhat.com \
--cc=daniel.lezcano@linaro.org \
--cc=hpa@zytor.com \
--cc=jbaron@akamai.com \
--cc=jpoimboe@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-users@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
--cc=luto@kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@kernel.org \
--cc=mingo@kernel.org \
--cc=namit@vmware.com \
--cc=pbonzini@redhat.com \
--cc=rafael.j.wysocki@intel.com \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=valentin.schneider@arm.com \
/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