From: Peter Zijlstra <peterz@infradead.org>
To: Fernand Sieber <sieberf@amazon.com>
Cc: kernel test robot <oliver.sang@intel.com>,
oe-lkp@lists.linux.dev, lkp@intel.com,
linux-kernel@vger.kernel.org, x86@kernel.org,
aubrey.li@linux.intel.com, yu.c.chen@intel.com,
jstultz@google.com
Subject: Re: [tip:sched/core] [sched/fair] 79104becf4: BUG:kernel_NULL_pointer_dereference,address
Date: Wed, 5 Nov 2025 13:28:08 +0100 [thread overview]
Message-ID: <20251105122808.GK988547@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <20251104210456.652800-1-sieberf@amazon.com>
On Tue, Nov 04, 2025 at 11:04:55PM +0200, Fernand Sieber wrote:
> Hi Peter,
>
> I spent some time today investigating this report. The crash happens when
> a proxy task yields.
>
> Since it probably doesn't make sense that a task blocking the best pick
> yields, a simple workaround is to ignore the yield in this case:
Well yield() as a whole doesn't make much sense outside of the strict RT
setting where it is well defined.
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -8993,6 +8993,11 @@ static void yield_task_fair(struct rq *rq)
> if (unlikely(rq->nr_running == 1))
> return;
>
> + /* Don't yield if we're running a proxy task */
> + if (rq->donor && rq->donor != curr) {
> + return;
> + }
Well, yield_task_fair() should probably have:
struct task_struct curr = rq->donor;
But yeah, if the task holding your resource is doing yield() you're
'sad'. Basically a sched-fair yield() means: I've no fucking clue what
I'm doing and lets hope we can make progress a little later.
And it gets worse in the context of PI/proxy, because in that case your
fair task can deadlock the system through sheer incompetence.
Anyway, consider the PI case, we bump a fair task to FIFO and then
yield() would do the FIFO yield -- with all the possible problems.
And we want the same for proxy, if the boosting context is FIFO, we want
a FIFO yield.
So I'm thinking, for all things to be consistent, we want something
like:
diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index 6b8a9286e2fc..13112c680f92 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -2143,7 +2143,7 @@ static void yield_task_dl(struct rq *rq)
* it and the bandwidth timer will wake it up and will give it
* new scheduling parameters (thanks to dl_yielded=1).
*/
- rq->curr->dl.dl_yielded = 1;
+ rq->donor->dl.dl_yielded = 1;
update_rq_clock(rq);
update_curr_dl(rq);
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 273e2871b59e..f1d8eb350f59 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -8980,7 +8980,7 @@ static void put_prev_task_fair(struct rq *rq, struct task_struct *prev, struct t
*/
static void yield_task_fair(struct rq *rq)
{
- struct task_struct *curr = rq->curr;
+ struct task_struct *curr = rq->donor;
struct cfs_rq *cfs_rq = task_cfs_rq(curr);
struct sched_entity *se = &curr->se;
diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
index 1fd97f2d7ec6..f1867fe8e5c5 100644
--- a/kernel/sched/rt.c
+++ b/kernel/sched/rt.c
@@ -1490,7 +1490,7 @@ static void requeue_task_rt(struct rq *rq, struct task_struct *p, int head)
static void yield_task_rt(struct rq *rq)
{
- requeue_task_rt(rq, rq->curr, 0);
+ requeue_task_rt(rq, rq->donor, 0);
}
static int find_lowest_rq(struct task_struct *task);
diff --git a/kernel/sched/syscalls.c b/kernel/sched/syscalls.c
index 8f0f603b530b..865ec5d6e824 100644
--- a/kernel/sched/syscalls.c
+++ b/kernel/sched/syscalls.c
@@ -1319,7 +1319,7 @@ static void do_sched_yield(void)
rq = this_rq_lock_irq(&rf);
schedstat_inc(rq->yld_count);
- current->sched_class->yield_task(rq);
+ rq->donor->sched_class->yield_task(rq);
preempt_disable();
rq_unlock_irq(rq, &rf);
next prev parent reply other threads:[~2025-11-05 12:28 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-21 5:14 kernel test robot
2025-10-21 6:39 ` Chen, Yu C
2025-10-21 11:04 ` Peter Zijlstra
2025-10-27 12:54 ` Peter Zijlstra
2025-10-27 13:14 ` Chen, Yu C
2025-10-27 13:55 ` Peter Zijlstra
2025-10-27 14:07 ` Peter Zijlstra
2025-10-27 14:09 ` Peter Zijlstra
2025-10-28 2:30 ` Chen, Yu C
2025-11-05 11:00 ` Peter Zijlstra
2025-11-05 12:06 ` Philip Li
2025-11-07 10:16 ` Philip Li
2025-11-07 10:53 ` Peter Zijlstra
2025-11-04 21:04 ` Fernand Sieber
2025-11-05 8:43 ` Fernand Sieber
2025-11-05 11:03 ` Peter Zijlstra
2025-11-05 12:28 ` Peter Zijlstra [this message]
2025-11-06 10:54 ` Fernand Sieber
2025-11-06 23:57 ` John Stultz
2025-11-07 8:18 ` Fernand Sieber
2025-11-06 10:40 [PATCH] sched: Proxy yields to donor tasks Fernand Sieber
2025-11-06 10:57 ` Peter Zijlstra
2025-11-07 6:54 ` kernel test robot
2025-11-07 8:12 ` Fernand Sieber
2025-11-07 8:25 ` Peter Zijlstra
2025-11-11 11:37 ` [tip: sched/core] sched/proxy: Yield the donor task tip-bot2 for Fernand Sieber
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=20251105122808.GK988547@noisy.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=aubrey.li@linux.intel.com \
--cc=jstultz@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@intel.com \
--cc=oe-lkp@lists.linux.dev \
--cc=oliver.sang@intel.com \
--cc=sieberf@amazon.com \
--cc=x86@kernel.org \
--cc=yu.c.chen@intel.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®