linux-kernel - Re: [PATCH] scx: set p->scx.ops_state using atomic_long_set

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: <ZXJgXqQlHc1mgd1m@slm.duckdns.org>
Date:   Thu, 7 Dec 2023 14:16:30 -1000
From:   Tejun Heo <tj@...nel.org>
To:     Changwoo Min <multics69@...il.com>
Cc:     kernel-dev@...lia.com, andrea.righi@...onical.com,
        andrii@...nel.org, ast@...nel.org, bpf@...r.kernel.org,
        brho@...gle.com, bristot@...hat.com, bsegall@...gle.com,
        changwoo@...lia.com, daniel@...earbox.net, derkling@...gle.com,
        dietmar.eggemann@....com, dschatzberg@...a.com,
        dskarlat@...cmu.edu, dvernet@...a.com, haoluo@...gle.com,
        himadrics@...ia.fr, joshdon@...gle.com, juri.lelli@...hat.com,
        kernel-team@...a.com, linux-kernel@...r.kernel.org,
        martin.lau@...nel.org, memxor@...il.com, mgorman@...e.de,
        mingo@...hat.com, peterz@...radead.org, pjt@...gle.com,
        riel@...riel.com, rostedt@...dmis.org,
        torvalds@...ux-foundation.org, vincent.guittot@...aro.org,
        vschneid@...hat.com
Subject: Re: [PATCH] scx: set p->scx.ops_state using atomic_long_set_release

Hello,

On Thu, Dec 07, 2023 at 11:04:59AM +0900, Changwoo Min wrote:
> p->scx.ops_state should be updated using the release semantics,
> atomic_long_set_release(), because it is read using
> atomic_long_read_acquire() at ops_dequeue() and wait_ops_state().
> ---
>  kernel/sched/ext.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/kernel/sched/ext.c b/kernel/sched/ext.c
> index 53ee906aa2b6..3a40ca2007b6 100644
> --- a/kernel/sched/ext.c
> +++ b/kernel/sched/ext.c
> @@ -881,7 +881,7 @@ static void do_enqueue_task(struct rq *rq, struct task_struct *p, u64 enq_flags,
>  	qseq = rq->scx.ops_qseq++ << SCX_OPSS_QSEQ_SHIFT;
>  
>  	WARN_ON_ONCE(atomic_long_read(&p->scx.ops_state) != SCX_OPSS_NONE);
> -	atomic_long_set(&p->scx.ops_state, SCX_OPSS_QUEUEING | qseq);
> +	atomic_long_set_release(&p->scx.ops_state, SCX_OPSS_QUEUEING | qseq);

atomic_long_load_acquire() are used when waiting the transitions out of
QUEUEING and DISPATCHING states. ie. the interlocking between writer and
reader is necessary only when transitioning out of those states. In the
above, @p is going into QUEUEING and release/acquire isn't necessary.
Selectively using them is kinda subtle but it's less confusing to keep it
that way, I think.

Thanks.

-- 
tejun