linux-kernel - RE: [PATCH 1/1] locking/qspinlock: Fix state-transition changes in comments

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] [day] [month] [year] [list]

Message-ID: <IA1PR11MB61715AB7C9D49459C89BA2D089779@IA1PR11MB6171.namprd11.prod.outlook.com>
Date:   Wed, 10 May 2023 05:28:05 +0000
From:   "Zhuo, Qiuxu" <qiuxu.zhuo@...el.com>
To:     Waiman Long <longman@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...hat.com>, Will Deacon <will@...nel.org>
CC:     Boqun Feng <boqun.feng@...il.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 1/1] locking/qspinlock: Fix state-transition changes in
 comments

> From: Waiman Long <longman@...hat.com>
> ...
> >
> > OK, so, you are from the point of view of the CPU (the lock word value
> > it read last time) doing state transition in the uncontended scenario:
> >
> >       [1]:  Old lock word value (this CPU read it last time) ---> New
> > lock word value
> >
> > I'm from the point of view of the current lock word possible value
> > that its state is transited to the new lock word possible value (I
> > don't think I'm the only one from this point of view when reading the
> qspinlock code ;-).
> >
> >       [2]: Current lock word possible value ---> New lock word
> > possible value
> >
> > I'm fine to keep the view of [1] in the current code and get [2] as the
> backup.
> > I'll send out a v2 with just two minor comments' fixes.
> 
> The purpose of those transition flow charts is to help understand what the
> code is doing. So they should reflect the running CPU point of view.
> If you want to show what all the possible values can be, you have to explicitly
> state that to avoid the confusion.

Yes, from the uncontended case view can help readers understand the qspinlock code.
After that, readers find that the qspinlock code also works for contended cases. 

Thank you for the clarification of the purpose of those state transition comments.

-Qiuxu

> Thanks,
> Longman