linux-kernel - Re: [PATCHSET v6] sched: Implement BPF extensible scheduler class

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: <ZnnUZp-_-igk1E3m@slm.duckdns.org>
Date: Mon, 24 Jun 2024 10:17:42 -1000
From: Tejun Heo <tj@...nel.org>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Thomas Gleixner <tglx@...utronix.de>,
	Linus Torvalds <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: [PATCHSET v6] sched: Implement BPF extensible scheduler class

Hello, Peter.

On Mon, Jun 24, 2024 at 11:34:26AM +0200, Peter Zijlstra wrote:
> I'm confused. Once you've loaded the BPF thing, 'all' tasks you care
> about should already be in the bpf class. So any fork() thereafter
> should not need to switch classes.
> 
> This means we can have this rwsem be strictly for the bpf tasks as
> Thomas suggested.
> 
> What are we missing?

Maybe I am confused but let's say the BPF scheduler gets unloaded and
reloaded. What would prevent a forking thread which didn't acquire the read
lock from racing against the second loading?

Also, let's say we can make it conditional but would the extra complication
be justifiable? percpu_down_read()'s hot path is one likely() cond test
followed by this_cpu_inc() wrapped in preempt_disable(). I'm not really sure
eliding that can justify much.

That said, as Thomas pointed out, the dl cancel path is silly. Let me clean
that up.

Thanks.

-- 
tejun