linux-kernel - Re: [PATCH] seqlock: Use WRITE

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: <93eea003-052d-4a9d-b8e8-a77043f59912@redhat.com>
Date: Wed, 18 Dec 2024 15:09:19 -0500
From: Waiman Long <llong@...hat.com>
To: paulmck@...nel.org, Waiman Long <llong@...hat.com>
Cc: Daniel Xu <dxu@...uu.xyz>, mingo@...hat.com, will@...nel.org,
 peterz@...radead.org, boqun.feng@...il.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] seqlock: Use WRITE_ONCE() when updating sequence


On 12/18/24 1:52 PM, Paul E. McKenney wrote:
>> If the compiler really uses the variable as a scratch storage, it will be a
>> problem if the variable can be accessed concurrently from multiple CPUs. It
>> is a new compiler optimization strategy that I am aware before. In that
>> case, we may really need a way to mark these variables as not suitable for
>> such advanced optimization.
> These markings already exist, namely, the "volatile" keyword, READ_ONCE(),
> WRITE_ONCE(), and hopefully soon INC_ONCE().  These last three use
> volatile accesses internally.
>
> The scratch-storage possibility exists only just before a normal
> C-language store, not before volatile accesses.  So a compiler is
> forbidden from doing that scratch-value-store trick before a volatile
> store.

I am aware of that in READ_ONCE() and WRITE_ONCE() and I am looking 
forward to have a INC_ONCE() and maybe DEC_ONCE() soon.

Cheers,
Longman