From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: Andrea Parri <parri.andrea@gmail.com>
Cc: Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
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>,
K Prateek Nayak <kprateek.nayak@amd.com>,
Clark Williams <clrkwllms@kernel.org>,
Dario Faggioli <raistlin@linux.it>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
linux-kernel@vger.kernel.org, linux-rt-devel@lists.linux.dev
Subject: Re: [PATCH] sched/deadline: Check SCHED_DEADLINE affinity under the rq lock
Date: Fri, 13 Nov 2026 16:35:49 +0100 [thread overview]
Message-ID: <20261113153549.Z8XPohWU@linutronix.de> (raw)
In-Reply-To: <20261105164856.29698-1-parri.andrea@gmail.com>
On 2026-11-05 17:48:43 [+0100], Andrea Parri wrote:
> __sched_setaffinity() calls dl_task_check_affinity() before
> __set_cpus_allowed_ptr() takes task_rq_lock(), whereas
> __sched_setscheduler() runs its admission test and switches the policy
> under a single task_rq_lock(). So both calls can pass their checks:
…
This looks fine to me. You do the check under the RQ lock so everything
that you checked can not change later on.
If you race with cpuset then you try to revert and drop that check-flag.
I can't comment on that. It looks wrong to set it to CPUs mask which not
part of the domain but you made a comment why it needs to happen. So
stay out here ;)
You could keep the check in __sched_setaffinity() so it bails out early
if it is not possible right away. The check under the RQ ist just due to
the race window that we have. But I don't have a strong opinion on that.
Anyway. The reported problem looks solved to me:
Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Sebastian
next prev parent reply other threads:[~2026-11-13 15:35 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-05 16:48 Andrea Parri
2026-11-13 15:06 ` Andrea Parri
2026-11-13 15:35 ` Sebastian Andrzej Siewior [this message]
2026-11-13 15:48 ` Andrea Parri
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=20261113153549.Z8XPohWU@linutronix.de \
--to=bigeasy@linutronix.de \
--cc=bsegall@google.com \
--cc=clrkwllms@kernel.org \
--cc=dietmar.eggemann@arm.com \
--cc=juri.lelli@redhat.com \
--cc=kprateek.nayak@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-devel@lists.linux.dev \
--cc=mathieu.desnoyers@efficios.com \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=parri.andrea@gmail.com \
--cc=peterz@infradead.org \
--cc=raistlin@linux.it \
--cc=rostedt@goodmis.org \
--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®