linux-kernel - Re: [PATCH 1/2] sched_ext: Track currently locked rq

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: <aAUybKUc3LyKZ3F4@slm.duckdns.org>
Date: Sun, 20 Apr 2025 07:44:12 -1000
From: Tejun Heo <tj@...nel.org>
To: Andrea Righi <arighi@...dia.com>
Cc: David Vernet <void@...ifault.com>, Changwoo Min <changwoo@...lia.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] sched_ext: Track currently locked rq

Hello,

On Sat, Apr 19, 2025 at 10:30:33PM +0200, Andrea Righi wrote:
> Hm... actually thinking more about this, a problem with the percpu variable
> is that, if no rq is locked, we could move to a different CPU and end up
> reading the wrong rq_locked via scx_locked_rq(). I don't think we want to
> preempt_disable/enable all the callbacks just to fix this... Maybe storing
> in current is a safer choice?

Hmm... I have a hard time imagining a timeline of events which would lead to
the wrong conclusion. The percpu variable is set only while an rq is locked
and cleared before the rq lock is released and thus can only be read as
non-NULL while the rq is locked by that CPU. Maybe I'm missing something.
Can you illustrate a timeline of events which would lead to the wrong
conclusion?

Thanks.

-- 
tejun