linux-kernel - Re: [PATCH 18/39] sched_ext: Allow BPF schedulers to disallow specific tasks from joining SCHED

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]

Date: Mon, 24 Jun 2024 14:40:53 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Tejun Heo <tj@...nel.org>
Cc: torvalds@...ux-foundation.org, mingo@...hat.com, juri.lelli@...hat.com,
	vincent.guittot@...aro.org, dietmar.eggemann@....com,
	rostedt@...dmis.org, bsegall@...gle.com, mgorman@...e.de,
	bristot@...hat.com, vschneid@...hat.com, ast@...nel.org,
	daniel@...earbox.net, andrii@...nel.org, martin.lau@...nel.org,
	joshdon@...gle.com, brho@...gle.com, pjt@...gle.com,
	derkling@...gle.com, haoluo@...gle.com, dvernet@...a.com,
	dschatzberg@...a.com, dskarlat@...cmu.edu, riel@...riel.com,
	changwoo@...lia.com, himadrics@...ia.fr, memxor@...il.com,
	andrea.righi@...onical.com, joel@...lfernandes.org,
	linux-kernel@...r.kernel.org, bpf@...r.kernel.org,
	kernel-team@...a.com
Subject: Re: [PATCH 18/39] sched_ext: Allow BPF schedulers to disallow
 specific tasks from joining SCHED_EXT

On Wed, May 01, 2024 at 05:09:53AM -1000, Tejun Heo wrote:
> BPF schedulers might not want to schedule certain tasks - e.g. kernel
> threads. This patch adds p->scx.disallow which can be set by BPF schedulers
> in such cases. The field can be changed anytime and setting it in
> ops.prep_enable() guarantees that the task can never be scheduled by
> sched_ext.

Why ?!?!

By leaving kernel threads fair, and fair sitting above the BPF thing,
it is not dissimilar to promoting them to FIFO. They will instantly
preempt the BPF thing and keep running for as long as they need. The
only real difference between this and actual FIFO is the behaviour on
contention.

This seems like a very bad thing to have, and your 'changelog' has no
justification what so ever.