linux-kernel - Re: [PATCH 2/4] sched_ext: Add scx_bpf_task_set_slice() and scx_bpf_task_set_dsq

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <aOVXR5sIPG_L8OLC@slm.duckdns.org>
Date: Tue, 7 Oct 2025 08:09:11 -1000
From: Tejun Heo <tj@...nel.org>
To: Emil Tsalapatis <linux-lists@...alapatis.com>
Cc: David Vernet <void@...ifault.com>, Andrea Righi <arighi@...dia.com>,
	Changwoo Min <changwoo@...lia.com>, linux-kernel@...r.kernel.org,
	sched-ext@...ts.linux.dev
Subject: Re: [PATCH 2/4] sched_ext: Add scx_bpf_task_set_slice() and
 scx_bpf_task_set_dsq_vtime()

Hello,

On Mon, Oct 06, 2025 at 10:56:45PM -0400, Emil Tsalapatis wrote:
> > +/**
> > + * scx_bpf_task_set_slice - Set task's time slice
> > + * @p: task of interest
> > + * @slice: time slice to set in nsecs
> > + *
> > + * Set @p's time slice to @slice. Returns %true on success, %false if the
> > + * calling scheduler doesn't have authority over @p.
> > + */
> > +__bpf_kfunc bool scx_bpf_task_set_slice(struct task_struct *p, u64 slice)
> > +{
> > +       p->scx.slice = slice;
> > +       return true;
> > +}
> > +
> 
> Q: Do we care about protecting slice/dsq_vtime these fields with a
> lock (e.g., to let them be atomically changed w/ other
> proc/DSQ state? If so, should we limit them with the kf_mask to be
> callable from specific BPF ops?

I think it'd be the calling BPF scheduler's responsibility to synchronize if
there are multiple writers. I don't think such scenarios are likely tho.
Schedulers almost always have clearly defined chain of custody for each
task. Also, there's nothing to synchronize on 64bit machines. These are
isolated writes (ie. adding locking doesn't change the possible outcomes).

Thanks.

-- 
tejun