From: Kuba Piecuch <jpiecuch@google.com>
To: Changwoo Min <changwoo@igalia.com>, <tj@kernel.org>,
<void@manifault.com>, <arighi@nvidia.com>
Cc: <kernel-dev@igalia.com>, <sched-ext@lists.linux.dev>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] sched_ext: Fix is_bpf_migration_disabled() false negative on non-PREEMPT_RCU
Date: Thu, 02 Apr 2026 14:13:22 +0000 [thread overview]
Message-ID: <DHIQBVSN95OQ.1UEKM573UIQFF@google.com> (raw)
In-Reply-To: <20260402023150.660967-1-changwoo@igalia.com>
Hi Changwoo,
On Thu Apr 2, 2026 at 2:31 AM UTC, Changwoo Min wrote:
...
> static bool is_bpf_migration_disabled(const struct task_struct *p)
> {
> - if (p->migration_disabled == 1)
> - return p != current;
> - else
> - return p->migration_disabled;
> + if (p->migration_disabled == 1) {
> + if (IS_ENABLED(CONFIG_PREEMPT_RCU))
> + return p != current;
> + return true;
> + }
> + return p->migration_disabled;
> }
The fix looks correct, but the logic looks somewhat convoluted. How about
something like this:
static bool is_bpf_migration_disabled(const struct task_struct *p)
{
- if (p->migration_disabled == 1)
- return p != current;
- else
- return p->migration_disabled;
+ if (IS_ENABLED(CONFIG_PREEMPT_RCU) &&
+ p == current &&
+ !WARN_ON_ONCE(!p->migration_disabled)) {
+ return p->migration_disabled - 1;
+ }
+ return p->migration_disabled;
}
My thinking here is: if CONFIG_PREEMPT_RCU is enabled and we're current,
subtract 1 from p->migration_disabled to account for the BPF prologue.
Otherwise just return p->migration_disabled. I've also thrown in a WARN_ON_ONCE
to help catch potential bugs if the assumption about the BPF prologue ever
changes.
Thanks,
Kuba
next prev parent reply other threads:[~2026-04-02 14:13 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-02 2:31 [PATCH] sched_ext: Fix is_bpf_migration_disabled() false negative on non-PREEMPT_RCU Changwoo Min
2026-04-02 9:45 ` Andrea Righi
2026-04-02 14:13 ` Kuba Piecuch [this message]
2026-04-02 19:28 ` Tejun Heo
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=DHIQBVSN95OQ.1UEKM573UIQFF@google.com \
--to=jpiecuch@google.com \
--cc=arighi@nvidia.com \
--cc=changwoo@igalia.com \
--cc=kernel-dev@igalia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=sched-ext@lists.linux.dev \
--cc=tj@kernel.org \
--cc=void@manifault.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.