kernel/locking/rtmutex.c | 3 --- 1 file changed, 3 deletions(-)
Anders had bisected a crash using PREEMPT_RT with linux-next and
isolated it down to commit 894d1b3db41c ("locking/mutex: Remove
wakeups from under mutex::wait_lock"), where it seemed the
wake_q structure was somehow getting corrupted causing a null
pointer traversal.
I was able to easily repoduce this with PREEMPT_RT and managed
to isolate down that through various call stacks we were
actually calling wake_up_q() twice on the same wake_q.
I found that in the problematic commit, I had added the
wake_up_q() call in task_blocks_on_rt_mutex() around
__ww_mutex_add_waiter(), following a similar pattern in
__mutex_lock_common().
However, its just wrong. We haven't dropped the lock->wait_lock,
so its contrary to the point of the original patch. And it
didn't match the __mutex_lock_common() logic of re-initializing
the wake_q after calling it midway in the stack.
Looking at it now, the wake_up_q() call is incorrect and should
just be removed. So drop the erronious logic I had added.
Anders: Can you double check this resolves the issue for you?
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Joel Fernandes <joelaf@google.com>
Cc: Qais Yousef <qyousef@layalina.io>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Juri Lelli <juri.lelli@redhat.com>
Cc: Vincent Guittot <vincent.guittot@linaro.org>
Cc: Dietmar Eggemann <dietmar.eggemann@arm.com>
Cc: Valentin Schneider <vschneid@redhat.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Benjamin Segall <bsegall@google.com>
Cc: Zimuzo Ezeozue <zezeozue@google.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Will Deacon <will@kernel.org>
Cc: Waiman Long <longman@redhat.com>
Cc: Boqun Feng <boqun.feng@gmail.com>
Cc: "Paul E. McKenney" <paulmck@kernel.org>
Cc: Metin Kaya <Metin.Kaya@arm.com>
Cc: Xuewen Yan <xuewen.yan94@gmail.com>
Cc: K Prateek Nayak <kprateek.nayak@amd.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: kernel-team@android.com
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: regressions@lists.linux.dev
Cc: Thorsten Leemhuis <linux@leemhuis.info>
Cc: Anders Roxell <anders.roxell@linaro.org>
Fixes: 894d1b3db41c ("locking/mutex: Remove wakeups from under mutex::wait_lock")
Reported-by: Anders Roxell <anders.roxell@linaro.org>
Reported-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/lkml/6afb936f-17c7-43fa-90e0-b9e780866097@app.fastmail.com/
Signed-off-by: John Stultz <jstultz@google.com>
---
kernel/locking/rtmutex.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c
index c7de80ee1f9d..a01e81179df0 100644
--- a/kernel/locking/rtmutex.c
+++ b/kernel/locking/rtmutex.c
@@ -1248,10 +1248,7 @@ static int __sched task_blocks_on_rt_mutex(struct rt_mutex_base *lock,
/* Check whether the waiter should back out immediately */
rtm = container_of(lock, struct rt_mutex, rtmutex);
- preempt_disable();
res = __ww_mutex_add_waiter(waiter, rtm, ww_ctx, wake_q);
- wake_up_q(wake_q);
- preempt_enable();
if (res) {
raw_spin_lock(&task->pi_lock);
rt_mutex_dequeue(lock, waiter);
--
2.47.0.277.g8800431eea-goog
Hello John, On 11/14/2024 3:22 AM, John Stultz wrote: > Anders had bisected a crash using PREEMPT_RT with linux-next and > isolated it down to commit 894d1b3db41c ("locking/mutex: Remove > wakeups from under mutex::wait_lock"), where it seemed the > wake_q structure was somehow getting corrupted causing a null > pointer traversal. > > I was able to easily repoduce this with PREEMPT_RT and managed > to isolate down that through various call stacks we were > actually calling wake_up_q() twice on the same wake_q. > > I found that in the problematic commit, I had added the > wake_up_q() call in task_blocks_on_rt_mutex() around > __ww_mutex_add_waiter(), following a similar pattern in > __mutex_lock_common(). > > However, its just wrong. We haven't dropped the lock->wait_lock, > so its contrary to the point of the original patch. And it > didn't match the __mutex_lock_common() logic of re-initializing > the wake_q after calling it midway in the stack. > > Looking at it now, the wake_up_q() call is incorrect and should > just be removed. So drop the erronious logic I had added. > > Anders: Can you double check this resolves the issue for you? > > Cc: Peter Zijlstra <peterz@infradead.org> > Cc: Joel Fernandes <joelaf@google.com> > Cc: Qais Yousef <qyousef@layalina.io> > Cc: Ingo Molnar <mingo@redhat.com> > Cc: Juri Lelli <juri.lelli@redhat.com> > Cc: Vincent Guittot <vincent.guittot@linaro.org> > Cc: Dietmar Eggemann <dietmar.eggemann@arm.com> > Cc: Valentin Schneider <vschneid@redhat.com> > Cc: Steven Rostedt <rostedt@goodmis.org> > Cc: Benjamin Segall <bsegall@google.com> > Cc: Zimuzo Ezeozue <zezeozue@google.com> > Cc: Mel Gorman <mgorman@suse.de> > Cc: Will Deacon <will@kernel.org> > Cc: Waiman Long <longman@redhat.com> > Cc: Boqun Feng <boqun.feng@gmail.com> > Cc: "Paul E. McKenney" <paulmck@kernel.org> > Cc: Metin Kaya <Metin.Kaya@arm.com> > Cc: Xuewen Yan <xuewen.yan94@gmail.com> > Cc: K Prateek Nayak <kprateek.nayak@amd.com> > Cc: Thomas Gleixner <tglx@linutronix.de> > Cc: Daniel Lezcano <daniel.lezcano@linaro.org> > Cc: kernel-team@android.com > Cc: Davidlohr Bueso <dave@stgolabs.net> > Cc: regressions@lists.linux.dev > Cc: Thorsten Leemhuis <linux@leemhuis.info> > Cc: Anders Roxell <anders.roxell@linaro.org> > Fixes: 894d1b3db41c ("locking/mutex: Remove wakeups from under mutex::wait_lock") > Reported-by: Anders Roxell <anders.roxell@linaro.org> > Reported-by: Arnd Bergmann <arnd@arndb.de> > Link: https://lore.kernel.org/lkml/6afb936f-17c7-43fa-90e0-b9e780866097@app.fastmail.com/ > Signed-off-by: John Stultz <jstultz@google.com> I've been running rtmutex_lock torture test in addition to a few standard micro-benchmarks with the fix on my system on top of tip:sched/core and I haven't encountered any splats there. Feel free to add: Tested-by: K Prateek Nayak <kprateek.nayak@amd.com> -- Thanks and Regards, Prateek > --- > kernel/locking/rtmutex.c | 3 --- > 1 file changed, 3 deletions(-) > > diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c > index c7de80ee1f9d..a01e81179df0 100644 > --- a/kernel/locking/rtmutex.c > +++ b/kernel/locking/rtmutex.c > @@ -1248,10 +1248,7 @@ static int __sched task_blocks_on_rt_mutex(struct rt_mutex_base *lock, > > /* Check whether the waiter should back out immediately */ > rtm = container_of(lock, struct rt_mutex, rtmutex); > - preempt_disable(); > res = __ww_mutex_add_waiter(waiter, rtm, ww_ctx, wake_q); > - wake_up_q(wake_q); > - preempt_enable(); > if (res) { > raw_spin_lock(&task->pi_lock); > rt_mutex_dequeue(lock, waiter);
On Wed, Nov 13, 2024 at 10:37 PM K Prateek Nayak <kprateek.nayak@amd.com> wrote: > On 11/14/2024 3:22 AM, John Stultz wrote: > > Anders had bisected a crash using PREEMPT_RT with linux-next and > > isolated it down to commit 894d1b3db41c ("locking/mutex: Remove > > wakeups from under mutex::wait_lock"), where it seemed the > > wake_q structure was somehow getting corrupted causing a null > > pointer traversal. > > > > I was able to easily repoduce this with PREEMPT_RT and managed > > to isolate down that through various call stacks we were > > actually calling wake_up_q() twice on the same wake_q. > > > > I found that in the problematic commit, I had added the > > wake_up_q() call in task_blocks_on_rt_mutex() around > > __ww_mutex_add_waiter(), following a similar pattern in > > __mutex_lock_common(). > > > > However, its just wrong. We haven't dropped the lock->wait_lock, > > so its contrary to the point of the original patch. And it > > didn't match the __mutex_lock_common() logic of re-initializing > > the wake_q after calling it midway in the stack. > > > > Looking at it now, the wake_up_q() call is incorrect and should > > just be removed. So drop the erronious logic I had added. > > ... > > I've been running rtmutex_lock torture test in addition to a few > standard micro-benchmarks with the fix on my system on top of > tip:sched/core and I haven't encountered any splats there. Feel free to > add: > > Tested-by: K Prateek Nayak <kprateek.nayak@amd.com> > Thank you so much for testing! I really appreciate it! I'll resend with the provided tags and without the RFC here soon. -john
On Wed, 13 Nov 2024 at 22:53, John Stultz <jstultz@google.com> wrote: > > Anders had bisected a crash using PREEMPT_RT with linux-next and > isolated it down to commit 894d1b3db41c ("locking/mutex: Remove > wakeups from under mutex::wait_lock"), where it seemed the > wake_q structure was somehow getting corrupted causing a null > pointer traversal. > > I was able to easily repoduce this with PREEMPT_RT and managed > to isolate down that through various call stacks we were > actually calling wake_up_q() twice on the same wake_q. > > I found that in the problematic commit, I had added the > wake_up_q() call in task_blocks_on_rt_mutex() around > __ww_mutex_add_waiter(), following a similar pattern in > __mutex_lock_common(). > > However, its just wrong. We haven't dropped the lock->wait_lock, > so its contrary to the point of the original patch. And it > didn't match the __mutex_lock_common() logic of re-initializing > the wake_q after calling it midway in the stack. > > Looking at it now, the wake_up_q() call is incorrect and should > just be removed. So drop the erronious logic I had added. > > Anders: Can you double check this resolves the issue for you? Thank you John for looking into the issue It booted just fine on the rockpi4 now, ontop of tag next-2024111. Tested-by: Anders Roxell <anders.roxell@linaro.org> Cheers, Anders > > Cc: Peter Zijlstra <peterz@infradead.org> > Cc: Joel Fernandes <joelaf@google.com> > Cc: Qais Yousef <qyousef@layalina.io> > Cc: Ingo Molnar <mingo@redhat.com> > Cc: Juri Lelli <juri.lelli@redhat.com> > Cc: Vincent Guittot <vincent.guittot@linaro.org> > Cc: Dietmar Eggemann <dietmar.eggemann@arm.com> > Cc: Valentin Schneider <vschneid@redhat.com> > Cc: Steven Rostedt <rostedt@goodmis.org> > Cc: Benjamin Segall <bsegall@google.com> > Cc: Zimuzo Ezeozue <zezeozue@google.com> > Cc: Mel Gorman <mgorman@suse.de> > Cc: Will Deacon <will@kernel.org> > Cc: Waiman Long <longman@redhat.com> > Cc: Boqun Feng <boqun.feng@gmail.com> > Cc: "Paul E. McKenney" <paulmck@kernel.org> > Cc: Metin Kaya <Metin.Kaya@arm.com> > Cc: Xuewen Yan <xuewen.yan94@gmail.com> > Cc: K Prateek Nayak <kprateek.nayak@amd.com> > Cc: Thomas Gleixner <tglx@linutronix.de> > Cc: Daniel Lezcano <daniel.lezcano@linaro.org> > Cc: kernel-team@android.com > Cc: Davidlohr Bueso <dave@stgolabs.net> > Cc: regressions@lists.linux.dev > Cc: Thorsten Leemhuis <linux@leemhuis.info> > Cc: Anders Roxell <anders.roxell@linaro.org> > Fixes: 894d1b3db41c ("locking/mutex: Remove wakeups from under mutex::wait_lock") > Reported-by: Anders Roxell <anders.roxell@linaro.org> > Reported-by: Arnd Bergmann <arnd@arndb.de> > Link: https://lore.kernel.org/lkml/6afb936f-17c7-43fa-90e0-b9e780866097@app.fastmail.com/ > Signed-off-by: John Stultz <jstultz@google.com> > --- > kernel/locking/rtmutex.c | 3 --- > 1 file changed, 3 deletions(-) > > diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c > index c7de80ee1f9d..a01e81179df0 100644 > --- a/kernel/locking/rtmutex.c > +++ b/kernel/locking/rtmutex.c > @@ -1248,10 +1248,7 @@ static int __sched task_blocks_on_rt_mutex(struct rt_mutex_base *lock, > > /* Check whether the waiter should back out immediately */ > rtm = container_of(lock, struct rt_mutex, rtmutex); > - preempt_disable(); > res = __ww_mutex_add_waiter(waiter, rtm, ww_ctx, wake_q); > - wake_up_q(wake_q); > - preempt_enable(); > if (res) { > raw_spin_lock(&task->pi_lock); > rt_mutex_dequeue(lock, waiter); > -- > 2.47.0.277.g8800431eea-goog >
© 2016 - 2024 Red Hat, Inc.