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]
Date: Wed, 5 Jun 2024 11:53:52 -0400
From: Alan Stern <stern@...land.harvard.edu>
To: Andrea Parri <parri.andrea@...il.com>
Cc: 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, hernan.poncedeleon@...weicloud.com,
  jonas.oberhauser@...weicloud.com
Subject: Re: [PATCH v2] tools/memory-model: Document herd7 (abstract)
 representation

On Wed, Jun 05, 2024 at 03:49:18PM +0200, Andrea Parri wrote:
> tools/memory-model/ and herdtool7 are closely linked: the latter is
> responsible for (pre)processing each C-like macro of a litmus test,
> and for providing the LKMM with a set of events, or "representation",
> corresponding to the given macro.  Provide herd-representation.txt
> to document the representations of the concurrency macros, following
> their "classification" in Documentation/atomic_t.txt.
> 
> Suggested-by: Hernan Ponce de Leon <hernan.poncedeleon@...weicloud.com>
> Signed-off-by: Andrea Parri <parri.andrea@...il.com>

> --- /dev/null
> +++ b/tools/memory-model/Documentation/herd-representation.txt
> @@ -0,0 +1,107 @@
> +#
> +# Legenda:
> +#	R,	a Load event
> +#	W,	a Store event
> +#	F,	a Fence event
> +#	LKR,	a Lock-Read event
> +#	LKW,	a Lock-Write event
> +#	UL,	an Unlock event
> +#	LF,	a Lock-Fail event
> +#	RL,	a Read-Locked event
> +#	RU,	a Read-Unlocked event
> +#	R*,	a Load event included in RMW
> +#	W*,	a Store event included in RMW
> +#	SRCU,	a Sleepable-Read-Copy-Update event
> +#
> +#	po,	a Program-Order link
> +#	rmw,	a Read-Modify-Write link
> +#	lk-rmw,	a Lock-Read-Modify-Write link

I wonder if we really need a special notation for lk-rmw.  Is anything 
wrong with using the normal rmw notation for these links?

Alan

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ