From: K Prateek Nayak <kprateek.nayak@amd.com>
To: "zhidao su (Xiaomi)" <soolaugust@gmail.com>,
John Stultz <jstultz@google.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Juri Lelli <juri.lelli@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Steven Rostedt <rostedt@goodmis.org>,
Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
Valentin Schneider <vschneid@redhat.com>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4] sched/proxy_exec: Detect cycles in proxy walks
Date: Tue, 21 Jul 2026 09:11:50 +0530 [thread overview]
Message-ID: <51450a8f-f053-45b3-a2fc-2bd0b75181b6@amd.com> (raw)
In-Reply-To: <20260717125512.865145-1-soolaugust@gmail.com>
Hello Zhidao,
On 7/17/2026 6:25 PM, zhidao su (Xiaomi) wrote:
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 2e7cde033a319..1a9d3decd66e0 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -2221,6 +2221,9 @@ void activate_task(struct rq *rq, struct task_struct *p, int flags)
> if (task_on_rq_migrating(p))
> flags |= ENQUEUE_MIGRATED;
>
> +#ifdef CONFIG_SCHED_PROXY_EXEC
> + p->proxy_pick_seq = 0;
> +#endif
nit.
I think it would be better if we have a sched_proxy_enqueue_task()
wrapper around this to avoid sprinkling #ifdef in otherwise what is a
clean function.
Also you can bail out early for !sched_proxy_exec() to avoid this write
for users who disable proxy execution at runtime.
> enqueue_task(rq, p, flags);
>
> WRITE_ONCE(p->on_rq, TASK_ON_RQ_QUEUED);
> @@ -6724,6 +6727,7 @@ static bool try_to_block_task(struct rq *rq, struct task_struct *p,
> }
>
> #ifdef CONFIG_SCHED_PROXY_EXEC
> +
> static inline void proxy_set_task_cpu(struct task_struct *p, int cpu)
> {
> unsigned int wake_cpu;
> @@ -6839,14 +6843,14 @@ static void proxy_migrate_task(struct rq *rq, struct rq_flags *rf,
> }
>
> /*
> - * Find runnable lock owner to proxy for mutex blocked donor
> + * Find runnable lock owner to proxy for a blocked donor
> *
> * Follow the blocked-on relation:
> *
> * ,-> task
> * | | blocked-on
> * | v
> - * blocked_donor | mutex
> + * blocked_donor | blocking primitive
> * | | owner
> * | v
> * `-- task
> @@ -6874,6 +6878,8 @@ find_proxy_task(struct rq *rq, struct task_struct *donor, struct rq_flags *rf)
> struct task_struct *p;
> int owner_cpu;
>
> + rq->proxy_pick_seq++;
> +
> /* Follow blocked_on chain. */
> for (p = donor; p->is_blocked; p = owner) {
> /* if its PROXY_WAKING, do return migration or run if current */
> @@ -6905,6 +6911,14 @@ find_proxy_task(struct rq *rq, struct task_struct *donor, struct rq_flags *rf)
> return NULL;
> }
>
> + if (p->proxy_pick_seq == rq->proxy_pick_seq) {
> + WARN_ONCE(1, "sched/pe: deadlock cycle detected, pid %d\n",
You can use pr_warn_once().
> + p->pid);
> + __clear_task_blocked_on(p, NULL);
> + goto deactivate;
> + }
> + p->proxy_pick_seq = rq->proxy_pick_seq;
> +
Do we need to do this here too? ...
> if (task_current(rq, p))
> curr_in_chain = true;
>
> @@ -6990,6 +7004,13 @@ find_proxy_task(struct rq *rq, struct task_struct *donor, struct rq_flags *rf)
> */
> return proxy_resched_idle(rq);
> }
> +
> + if (owner->proxy_pick_seq == rq->proxy_pick_seq) {
> + WARN_ONCE(1, "sched/pe: deadlock cycle detected, pid %d\n",
> + p->pid);
> + __clear_task_blocked_on(p, NULL);
> + goto deactivate;
> + }
... This should be sufficient right? You can just set
owner->proxy_pick_seq = rq->proxy_pick_seq;
below once owner is finalized instead of setting "p->proxy_pick_seq"
very early above.
> /*
> * OK, now we're absolutely sure @owner is on this
> * rq, therefore holding @rq->lock is sufficient to
Apart from those, the patch looks good. With the comments addressed,
feel free to include:
Reviewed-by: K Prateek Nayak <kprateek.nayak@amd.com>
--
Thanks and Regards,
Prateek
next prev parent reply other threads:[~2026-07-21 3:42 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-14 5:36 [PATCH] sched/proxy_exec: Limit find_proxy_task() chain depth to prevent CPU hang soolaugust
2026-04-21 2:27 ` John Stultz
2026-04-21 3:13 ` K Prateek Nayak
2026-04-21 12:02 ` zhidao su
2026-04-21 12:08 ` zhidao su
2026-07-14 15:21 ` [PATCH v2] sched/proxy_exec: Break cyclic proxy chains by deactivating blocked tasks soolaugust
2026-07-14 20:46 ` K Prateek Nayak
2026-07-15 2:37 ` soolaugust
2026-07-15 3:01 ` K Prateek Nayak
2026-07-15 8:50 ` zhidao su
2026-07-17 10:52 ` [PATCH v3] sched/proxy_exec: Detect cycles in proxy walks zhidao su (Xiaomi)
2026-07-17 11:50 ` K Prateek Nayak
2026-07-17 12:55 ` [PATCH v4] " zhidao su (Xiaomi)
2026-07-21 3:41 ` K Prateek Nayak [this message]
2026-07-22 12:03 ` [PATCH v5] " zhidao su (Xiaomi)
2026-08-12 21:29 ` John Stultz
2026-08-13 4:09 ` zhidao su
2026-09-14 17:10 ` Hui Su
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=51450a8f-f053-45b3-a2fc-2bd0b75181b6@amd.com \
--to=kprateek.nayak@amd.com \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=jstultz@google.com \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=soolaugust@gmail.com \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.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
all inboxes | Powered by JetHome®