linux-kernel - Re: [PATCH next 3/5] locking/osq_lock: Clarify osq_wait

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: <CAHk-=wj3pHPAyNNaZ78u-RA=iwN8CPkfe69txoK=b0oKdKfROA@mail.gmail.com>
Date: Fri, 29 Dec 2023 14:54:00 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: David Laight <David.Laight@...lab.com>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, 
	"peterz@...radead.org" <peterz@...radead.org>, "longman@...hat.com" <longman@...hat.com>, 
	"mingo@...hat.com" <mingo@...hat.com>, "will@...nel.org" <will@...nel.org>, 
	"boqun.feng@...il.com" <boqun.feng@...il.com>, 
	"xinhui.pan@...ux.vnet.ibm.com" <xinhui.pan@...ux.vnet.ibm.com>, 
	"virtualization@...ts.linux-foundation.org" <virtualization@...ts.linux-foundation.org>, 
	Zeng Heng <zengheng4@...wei.com>
Subject: Re: [PATCH next 3/5] locking/osq_lock: Clarify osq_wait_next()

On Fri, 29 Dec 2023 at 12:56, David Laight <David.Laight@...lab.com> wrote:
>
> osq_wait_next() is passed 'prev' from osq_lock() and NULL from osq_unlock()
> but only needs the 'cpu' value to write to lock->tail.
> Just pass prev->cpu or OSQ_UNLOCKED_VAL instead.
>
> Also directly return NULL or 'next' instead of breaking the loop.

Please split these two totally independent things out of the patch,
just to make things much more obvious.

I like the new calling convention, but I don't like how the patch
isn't obviously just that.

In fact, I'd take your patch #1 and just the calling convention change
from #3 as "these are obviously not changing anything at all, only
moving things to more local places".

I'd also take the other part of #3 as a "clearly doesn't change
anything" but it should be a separate patch, and it should be done
differently: make 'next' be local to just *inside* the for-loop (in
fact, make it local to the if-statement that sets it), to clarify the
whole thing that it can never be non-NULL at the top of the loop, and
can never have any long-term semantics.

The other parts actually change some logic, and would need the OSQ
people to take a more serious look.

            Linus