linux-kernel - Re: [PATCH v4 1/2] sched_ext: Add lockless peek operation for DSQs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <aO_Fl0Zpeh9pvMFB@gpd4>
Date: Wed, 15 Oct 2025 18:02:31 +0200
From: Andrea Righi <arighi@...dia.com>
To: Christian Loehle <christian.loehle@....com>
Cc: Ryan Newton <rrnewton@...il.com>, linux-kernel@...r.kernel.org,
	sched-ext@...ts.linux.dev, tj@...nel.org, newton@...a.com
Subject: Re: [PATCH v4 1/2] sched_ext: Add lockless peek operation for DSQs

On Wed, Oct 15, 2025 at 10:46:52AM +0100, Christian Loehle wrote:
> On 10/15/25 02:57, Ryan Newton wrote:
...
> > --- a/tools/sched_ext/include/scx/compat.bpf.h
> > +++ b/tools/sched_ext/include/scx/compat.bpf.h
> > @@ -26,6 +26,24 @@ int bpf_cpumask_populate(struct cpumask *dst, void *src, size_t src__sz) __ksym
> >  	(bpf_ksym_exists(bpf_cpumask_populate) ?			\
> >  	 (bpf_cpumask_populate(cpumask, src, size__sz)) : -EOPNOTSUPP)
> >  
> > +/*
> > + * v6.19: Introduce lockless peek API for user DSQs.
> > + *
> > + * Preserve the following macro until v6.21.
> > + */
> > +static inline struct task_struct *__COMPAT_scx_bpf_dsq_peek(u64 dsq_id)
> > +{
> > +	struct task_struct *p = NULL;
> > +	struct bpf_iter_scx_dsq it;
> > +
> > +	if (bpf_ksym_exists(scx_bpf_dsq_peek))
> > +		return scx_bpf_dsq_peek(dsq_id);
> > +	if (!bpf_iter_scx_dsq_new(&it, dsq_id, 0))
> > +		p = bpf_iter_scx_dsq_next(&it);
> > +	bpf_iter_scx_dsq_destroy(&it);
> > +	return p;
> > +}
> > +
> I think there's an argument to be made for this to just return NULL on
> !bpf_ksym_exists(scx_bpf_dsq_peek), the caller needs to handle that anyway
> and at least it's guaranteed to be lockfree then?
> I don't have a strong leaning either way, probably is fine if documented.

If we return NULL, the caller cannot tell whether the DSQ is empty or the
kfunc is missing. Honestly, I don't think being lockless is a strict
requirement from a scheduler's perspective, but if there's a case where it
matters, we can add a separate helper, i.e., scx_bpf_dsq_peek_nolock(),
that explicitly returns NULL when scx_bpf_dsq_peek() is unavailable.

Thanks,
-Andrea