linux-kernel - Re: [PATCH 10/11] sched_ext: Implement scx_bpf_dispatch[_vtime]_from

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 for Android: free password hash cracker in your pocket

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

Message-ID: <fbca5a6c-d1c2-488a-a605-7403aa7db21e@gmail.com>
Date: Mon, 2 Sep 2024 10:53:33 +0900
From: Changwoo Min <multics69@...il.com>
To: Andrea Righi <andrea.righi@...ux.dev>, Tejun Heo <tj@...nel.org>
Cc: void@...ifault.com, kernel-team@...a.com, linux-kernel@...r.kernel.org,
 Daniel Hodges <hodges.daniel.scott@...il.com>,
 Dan Schatzberg <schatzberg.dan@...il.com>,
 "kernel-dev@...lia.com" <kernel-dev@...lia.com>
Subject: Re: [PATCH 10/11] sched_ext: Implement
 scx_bpf_dispatch[_vtime]_from_dsq()



On 24. 9. 1. 06:15, Andrea Righi wrote:

>>>> +__bpf_kfunc bool scx_bpf_dispatch_from_dsq(struct bpf_iter_scx_dsq *it__iter,
>>>> +					   struct task_struct *p, u64 dsq_id,
>>>> +					   u64 slice, u64 enq_flags)
>>>> +{
>>>> +	return scx_dispatch_from_dsq((struct bpf_iter_scx_dsq_kern *)it__iter,
>>>> +				     p, dsq_id, slice, 0, enq_flags);
>>>> +}
>>>> +
>>>> +/**
>>>> + * scx_bpf_dispatch_vtime_from_dsq - Move a task from DSQ iteration to a PRIQ DSQ
>>>> + * @it__iter: DSQ iterator in progress
>>>> + * @p: task to transfer
>>>> + * @dsq_id: DSQ to move @p to
>>>> + * @slice: duration @p can run for in nsecs, 0 to keep the current value
>>>> + * @vtime: @p's ordering inside the vtime-sorted queue of the target DSQ
>>>> + * @enq_flags: SCX_ENQ_*
>>>
>>> Hm... can we pass 6 arguments to a kfunc? I think we're limited to 5,
>>> unless I'm missing something here.
>>
>> Hah, I actually don't know and didn't test the vtime variant. Maybe I should
>> just drop the @slice and @vtime. They can be set by the caller explicitly
>> before calling these kfuncs anyway although there are some concerns around
>> ownership (ie. the caller can't be sure that the task has already been
>> dispatched by someone else before scx_bpf_dispatch_from_dsq() commits). Or
>> maybe I should pack the optional arguments into a struct. I'll think more
>> about it.
> 
> IMHO we can simply drop them, introducing a separate struct makes the
> API a bit inconsistent with scx_bpf_dispatch() (and I don't think we
> want to change also scx_bpf_dispatch() for that).

Dropping @slice and @vtime would be cleaner in terms of the API
interface. Some use cases simply move a task from one DSQ to
another (e.g., from a shared DSQ to a per-domain DSQ).