[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250910183555.GV3289052@noisy.programming.kicks-ass.net>
Date: Wed, 10 Sep 2025 20:35:55 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Andrea Righi <arighi@...dia.com>
Cc: tj@...nel.org, linux-kernel@...r.kernel.org, mingo@...hat.com,
juri.lelli@...hat.com, vincent.guittot@...aro.org,
dietmar.eggemann@....com, rostedt@...dmis.org, bsegall@...gle.com,
mgorman@...e.de, vschneid@...hat.com, longman@...hat.com,
hannes@...xchg.org, mkoutny@...e.com, void@...ifault.com,
changwoo@...lia.com, cgroups@...r.kernel.org,
sched-ext@...ts.linux.dev, liuwenfang@...or.com, tglx@...utronix.de
Subject: Re: [PATCH 00/14] sched: Support shared runqueue locking
On Wed, Sep 10, 2025 at 07:32:12PM +0200, Andrea Righi wrote:
> [ 15.160400] Call Trace:
> [ 15.160706] dequeue_task_scx+0x14a/0x270
> [ 15.160857] move_queued_task+0x7d/0x2d0
> [ 15.160952] affine_move_task+0x6ca/0x700
> [ 15.161210] __set_cpus_allowed_ptr+0x64/0xa0
> [ 15.161348] __sched_setaffinity+0x72/0x100
> [ 15.161459] sched_setaffinity+0x261/0x2f0
> [ 15.161569] __x64_sys_sched_setaffinity+0x50/0x80
> [ 15.161705] do_syscall_64+0xbb/0x370
> [ 15.161816] entry_SYSCALL_64_after_hwframe+0x77/0x7f
>
> Are we missing a DEQUEUE_LOCKED in the sched_setaffinity() path?
Yeah, the affine_move_task->move_queued_task path is messed up. It
relied on raw_spin_lock_irqsave(&p->pi_lock); rq_lock(rq); being
equivalent to task_rq_lock(), which is no longer true.
I fixed a few such sites earlier today but missed this one.
I'll go untangle it, but probably something for tomorrow, I'm bound to
make a mess of it now :-)
Powered by blists - more mailing lists