The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Changwoo Min <changwoo@igalia.com>
To: tj@kernel.org, void@manifault.com, arighi@nvidia.com
Cc: kernel-dev@igalia.com, linux-kernel@vger.kernel.org,
	Changwoo Min <changwoo@igalia.com>
Subject: [PATCH 3/4] sched_ext: Add __COMPAT_is_enq_cpu_selected() for BPF compatability
Date: Sat,  8 Feb 2025 13:43:31 +0900	[thread overview]
Message-ID: <20250208044332.492494-4-changwoo@igalia.com> (raw)
In-Reply-To: <20250208044332.492494-1-changwoo@igalia.com>

Suppose a BPF scheduler is compiled against the vmlinux.h that has
SCX_ENQ_CPU_SELECTED, but it runs on an old kernel where SCX_ENQ_CPU_SELECTED
is not defined. In this case, the test result of
'enq_flags & SCX_ENQ_CPU_SELECTED' will always be false. That test result is
semantically incorrect because the kernel before SCX_ENQ_CPU_SELECTED has
never skipped select_task_rq_scx(), so the result should be true.
To hide such complexity, introduce __COMPAT_is_enq_cpu_selected(), which
checks if SCX_ENQ_CPU_SELECTED exists in runtime using BPF CO-RE.

Signed-off-by: Changwoo Min <changwoo@igalia.com>
---
 tools/sched_ext/include/scx/compat.bpf.h | 52 ++++++++++++++++++++++++
 1 file changed, 52 insertions(+)

diff --git a/tools/sched_ext/include/scx/compat.bpf.h b/tools/sched_ext/include/scx/compat.bpf.h
index 50e1499ae093..e5fa72f9bf22 100644
--- a/tools/sched_ext/include/scx/compat.bpf.h
+++ b/tools/sched_ext/include/scx/compat.bpf.h
@@ -125,6 +125,58 @@ bool scx_bpf_dispatch_vtime_from_dsq___compat(struct bpf_iter_scx_dsq *it__iter,
 	false;									\
 })
 
+/**
+ * __COMPAT_is_enq_cpu_selected - Test if SCX_ENQ_CPU_SELECTED is on
+ * in a compatible way. We will preserve this __COMPAT helper until v6.16.
+ *
+ * @enq_flags: enqueue flags from ops.enqueue()
+ *
+ * Return: True if SCX_ENQ_CPU_SELECTED is turned on in @enq_flags
+ */
+static inline bool __COMPAT_is_enq_cpu_selected(u64 enq_flags)
+{
+#ifdef HAVE_SCX_ENQ_CPU_SELECTED
+	/*
+	 * This is the case that a BPF code compiled against vmlinux.h
+	 * where the enum SCX_ENQ_CPU_SELECTED exists.
+	 */
+
+	/*
+	 * We should temporarily suspend the macro expansion of
+	 * 'SCX_ENQ_CPU_SELECTED'. This avoids 'SCX_ENQ_CPU_SELECTED' being
+	 * rewritten to '__SCX_ENQ_CPU_SELECTED' when 'SCX_ENQ_CPU_SELECTED'
+	 * is defined in 'scripts/gen_enums.py'.
+	 */
+#pragma push_macro("SCX_ENQ_CPU_SELECTED")
+#undef SCX_ENQ_CPU_SELECTED
+	u64 flag;
+
+	/*
+	 * When the kernel did not have SCX_ENQ_CPU_SELECTED,
+	 * select_task_rq_scx() has never been skipped. Thus, this case
+	 * should be considered that the CPU has already been selected.
+	 */
+	if (!bpf_core_enum_value_exists(enum scx_enq_flags,
+					SCX_ENQ_CPU_SELECTED))
+		return true;
+
+	flag = bpf_core_enum_value(enum scx_enq_flags, SCX_ENQ_CPU_SELECTED);
+	return enq_flags & flag;
+
+	/*
+	 * Once done, resume the macro expansion of 'SCX_ENQ_CPU_SELECTED'.
+	 */
+#pragma pop_macro("SCX_ENQ_CPU_SELECTED")
+#else
+	/*
+	 * This is the case that a BPF code compiled against vmlinux.h
+	 * where the enum SCX_ENQ_CPU_SELECTED does NOT exist.
+	 */
+	return true;
+#endif /* HAVE_SCX_ENQ_CPU_SELECTED */
+}
+
+
 #define scx_bpf_now()								\
 	(bpf_ksym_exists(scx_bpf_now) ?						\
 	 scx_bpf_now() :							\
-- 
2.48.1


  parent reply	other threads:[~2025-02-08  4:44 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-08  4:43 [PATCH 0/4] sched_ext: Compatible testing of SCX_ENQ_CPU_SELECTED Changwoo Min
2025-02-08  4:43 ` [PATCH 1/4] sched_ext: Add enum_defs.autogen.h Changwoo Min
2025-02-08  4:43 ` [PATCH 2/4] sched_ext: Include enum_defs.autogen.h from common/common.bpf.h Changwoo Min
2025-02-08  4:43 ` Changwoo Min [this message]
2025-02-08  4:43 ` [PATCH 4/4] sched_ext: Use __COMPAT_is_enq_cpu_selected() in scx_qmap Changwoo Min
2025-02-08  8:13 ` [PATCH 0/4] sched_ext: Compatible testing of SCX_ENQ_CPU_SELECTED Tejun Heo
2025-02-08  9:04   ` Changwoo Min

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=20250208044332.492494-4-changwoo@igalia.com \
    --to=changwoo@igalia.com \
    --cc=arighi@nvidia.com \
    --cc=kernel-dev@igalia.com \
    --cc=linux-kernel@vger.kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox