linux-kernel - Re: [PATCH] locking/atomic: scripts: clarify ordering of conditional atomics

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: <20240206184005.4125128-1-nphamcs@gmail.com>
Date: Tue,  6 Feb 2024 10:40:05 -0800
From: Nhat Pham <nphamcs@...il.com>
To: mark.rutland@....com
Cc: linux-kernel@...r.kernel.org,
	boqun.feng@...il.com,
	frederic@...nel.org,
	joel@...lfernandes.org,
	neeraj.iitr10@...il.com,
	paulmck@...nel.org,
	peterz@...radead.org,
	will@...nel.org
Subject: Re: [PATCH] locking/atomic: scripts: clarify ordering of conditional atomics

Let me bring in some beginners' perspective :)

For the most part, LGTM! My only comment is regarding the conditional
atomics with relaxed ordering on success:

/**
  * If (@v == @old), atomically updates @v to @new with relaxed ordering.
+ * Otherwise, @v is not modified and no ordering is provided.

This is technically correct, but it can be confusing. It reads as if
"relaxed ordering" is much different from no ordering, since we are
juxtaposing them when we compare what happens when the condition holds
v.s when it does not.

This can be potentially confusing to unfamiliar users. I consulted
with Paul about this, and he suggested this rewording, which I like
better:

"Otherwise, @v is not modified and relaxed ordering is provided."

With something along that line in place:
Reviewed-by: Nhat Pham <nphamcs@...il.com>