linux-kernel - Re: [PATCH] tools/memory-model: Document herd7 (internal) representation

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: <5a9bc579-01ad-0b0f-bcba-c8f0bd932331@huaweicloud.com>
Date: Mon, 27 May 2024 19:57:41 +0200
From: Hernan Ponce de Leon <hernan.poncedeleon@...weicloud.com>
To: Andrea Parri <parri.andrea@...il.com>
Cc: stern@...land.harvard.edu, will@...nel.org, peterz@...radead.org,
 boqun.feng@...il.com, npiggin@...il.com, dhowells@...hat.com,
 j.alglave@....ac.uk, luc.maranget@...ia.fr, paulmck@...nel.org,
 akiyks@...il.com, dlustig@...dia.com, joel@...lfernandes.org,
 linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org,
 jonas.oberhauser@...weicloud.com
Subject: Re: [PATCH] tools/memory-model: Document herd7 (internal)
 representation

On 5/27/2024 3:28 PM, Andrea Parri wrote:
>>> +    |                smp_store_mb | W[once] ->po F[mb]                        |
>>
>> I expect this one to be hard-coded in herd7 source code, but I cannot find
>> it. Can you give me a pointer?
> 
> smp_store_mb() is currently mapped to { __store{once}(X,V); __fence{mb}; } in
> the .def file, so it's semantically equivalent to "WRITE_ONCE(); smp_mb();".

Ok, so some fences where added in the .def file (this) while other 
programmatically (e.g., xchg). We should at least be consistent about 
how this is done. Based on previous comments, it seems most of us agree 
this should go the the .def file.

> 
> 
>> What about spin_unlock?
> 
> spin_unlock() is listed among the non-RMW ops/macros in the current table: it
> is represented by a single UL or "Unlock" event (a special type of Store event
> with (some special) Release semantics).

I was blind. Sorry for the noise.

> 
> 
>> I found the extra spaces in the failure case very hard to read. Any
>> particular reason why you went with this format?
> 
> The extra spaces were simply to convey something like "belong to the previous
> row/entry", but I'm open to remove them or other suggestions if preferred.

I find it easier to read without the extra spaces. The empty column on 
the left already tells me this is a continuation of the previous row.
But I don't see this as a blocker.

> 
>    Andrea