From: Peter Zijlstra <peterz@infradead.org>
To: John Stultz <jstultz@google.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
K Prateek Nayak <kprateek.nayak@amd.com>,
Joel Fernandes <joelagnelf@nvidia.com>,
Qais Yousef <qyousef@layalina.io>, Ingo Molnar <mingo@redhat.com>,
Juri Lelli <juri.lelli@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Valentin Schneider <vschneid@redhat.com>,
Steven Rostedt <rostedt@goodmis.org>,
Ben Segall <bsegall@google.com>,
Zimuzo Ezeozue <zezeozue@google.com>,
Mel Gorman <mgorman@suse.de>, Will Deacon <will@kernel.org>,
Waiman Long <longman@redhat.com>,
Boqun Feng <boqun.feng@gmail.com>,
"Paul E. McKenney" <paulmck@kernel.org>,
Metin Kaya <Metin.Kaya@arm.com>,
Xuewen Yan <xuewen.yan94@gmail.com>,
Thomas Gleixner <tglx@linutronix.de>,
Daniel Lezcano <daniel.lezcano@linaro.org>,
Suleiman Souhlal <suleiman@google.com>,
kuyo chang <kuyo.chang@mediatek.com>, hupu <hupu.gm@gmail.com>,
kernel-team@android.com
Subject: Re: [PATCH v22 1/6] locking: Add task::blocked_lock to serialize blocked_on state
Date: Wed, 8 Oct 2025 12:27:22 +0200 [thread overview]
Message-ID: <20251008102722.GT3419281@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <20250926032931.27663-2-jstultz@google.com>
On Fri, Sep 26, 2025 at 03:29:09AM +0000, John Stultz wrote:
> So far, we have been able to utilize the mutex::wait_lock
> for serializing the blocked_on state, but when we move to
> proxying across runqueues, we will need to add more state
> and a way to serialize changes to this state in contexts
> where we don't hold the mutex::wait_lock.
>
> So introduce the task::blocked_lock, which nests under the
> mutex::wait_lock in the locking order, and rework the locking
> to use it.
>
> Signed-off-by: John Stultz <jstultz@google.com>
> Reviewed-by: K Prateek Nayak <kprateek.nayak@amd.com>
> ---
> include/linux/sched.h | 52 +++++++++++++++---------------------
> init/init_task.c | 1 +
> kernel/fork.c | 1 +
> kernel/locking/mutex-debug.c | 4 +--
> kernel/locking/mutex.c | 40 +++++++++++++++++----------
> kernel/locking/ww_mutex.h | 4 +--
> kernel/sched/core.c | 4 ++-
> 7 files changed, 57 insertions(+), 49 deletions(-)
>
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index e4ce0a76831e5..cb4e81d9d9b67 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> +static inline struct mutex *get_task_blocked_on(struct task_struct *p)
> +{
> + guard(raw_spinlock_irqsave)(&p->blocked_lock);
> + return __get_task_blocked_on(p);
> }
This isn't a safe function in general; nothing guarantees the value
returned is stable. Perhaps move it inside kernel/locking/mutex.h, its
only users (below) are mutex debug code after all.
> diff --git a/kernel/locking/mutex-debug.c b/kernel/locking/mutex-debug.c
> index 949103fd8e9b5..1d8cff71f65e1 100644
> --- a/kernel/locking/mutex-debug.c
> +++ b/kernel/locking/mutex-debug.c
> @@ -54,13 +54,13 @@ void debug_mutex_add_waiter(struct mutex *lock, struct mutex_waiter *waiter,
> lockdep_assert_held(&lock->wait_lock);
>
> /* Current thread can't be already blocked (since it's executing!) */
> - DEBUG_LOCKS_WARN_ON(__get_task_blocked_on(task));
> + DEBUG_LOCKS_WARN_ON(get_task_blocked_on(task));
> }
>
> void debug_mutex_remove_waiter(struct mutex *lock, struct mutex_waiter *waiter,
> struct task_struct *task)
> {
> - struct mutex *blocked_on = __get_task_blocked_on(task);
> + struct mutex *blocked_on = get_task_blocked_on(task);
>
> DEBUG_LOCKS_WARN_ON(list_empty(&waiter->list));
> DEBUG_LOCKS_WARN_ON(waiter->task != task);
> diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c
> index de7d6702cd96c..c44fc63d4476e 100644
> --- a/kernel/locking/mutex.c
> +++ b/kernel/locking/mutex.c
> @@ -740,11 +752,11 @@ __mutex_lock_common(struct mutex *lock, unsigned int state, unsigned int subclas
> return 0;
>
> err:
> - __clear_task_blocked_on(current, lock);
> + clear_task_blocked_on(current, lock);
> __set_current_state(TASK_RUNNING);
> __mutex_remove_waiter(lock, &waiter);
> err_early_kill:
> - WARN_ON(__get_task_blocked_on(current));
> + WARN_ON(get_task_blocked_on(current));
> trace_contention_end(lock, ret);
> raw_spin_unlock_irqrestore_wake(&lock->wait_lock, flags, &wake_q);
> debug_mutex_free_waiter(&waiter);
next prev parent reply other threads:[~2025-10-08 10:28 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-26 3:29 [PATCH v22 0/6] Donor Migration for Proxy Execution (v22) John Stultz
2025-09-26 3:29 ` [PATCH v22 1/6] locking: Add task::blocked_lock to serialize blocked_on state John Stultz
2025-10-08 10:27 ` Peter Zijlstra [this message]
2025-09-26 3:29 ` [PATCH v22 2/6] sched/locking: Add blocked_on_state to provide necessary tri-state for proxy return-migration John Stultz
2025-10-08 11:26 ` Peter Zijlstra
2025-10-09 0:07 ` John Stultz
2025-10-09 11:43 ` Peter Zijlstra
2025-10-09 11:45 ` Peter Zijlstra
2025-10-14 2:43 ` John Stultz
2025-10-16 22:23 ` John Stultz
2025-09-26 3:29 ` [PATCH v22 3/6] sched: Add logic to zap balance callbacks if we pick again John Stultz
2025-10-08 11:37 ` Peter Zijlstra
2025-09-26 3:29 ` [PATCH v22 4/6] sched: Handle blocked-waiter migration (and return migration) John Stultz
2025-10-08 13:32 ` Peter Zijlstra
2025-10-16 0:15 ` John Stultz
2025-09-26 3:29 ` [PATCH v22 5/6] sched: Add blocked_donor link to task for smarter mutex handoffs John Stultz
2025-09-26 3:29 ` [PATCH v22 6/6] sched: Migrate whole chain in proxy_migrate_task() John Stultz
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=20251008102722.GT3419281@noisy.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=Metin.Kaya@arm.com \
--cc=boqun.feng@gmail.com \
--cc=bsegall@google.com \
--cc=daniel.lezcano@linaro.org \
--cc=dietmar.eggemann@arm.com \
--cc=hupu.gm@gmail.com \
--cc=joelagnelf@nvidia.com \
--cc=jstultz@google.com \
--cc=juri.lelli@redhat.com \
--cc=kernel-team@android.com \
--cc=kprateek.nayak@amd.com \
--cc=kuyo.chang@mediatek.com \
--cc=linux-kernel@vger.kernel.org \
--cc=longman@redhat.com \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=paulmck@kernel.org \
--cc=qyousef@layalina.io \
--cc=rostedt@goodmis.org \
--cc=suleiman@google.com \
--cc=tglx@linutronix.de \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.com \
--cc=will@kernel.org \
--cc=xuewen.yan94@gmail.com \
--cc=zezeozue@google.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 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.