linux-kernel - Re: [PATCH] documentation: explain memory barriers

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: <8119.1223517003@turing-police.cc.vt.edu>
Date:	Wed, 08 Oct 2008 21:50:03 -0400
From:	Valdis.Kletnieks@...edu
To:	Randy Dunlap <randy.dunlap@...cle.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Ben Hutchings <bhutchings@...arflare.com>,
	Mikulas Patocka <mpatocka@...hat.com>,
	linux-kernel@...r.kernel.org, linux-mm@...r.kernel.org
Subject: Re: [PATCH] documentation: explain memory barriers

On Wed, 08 Oct 2008 18:12:23 PDT, Randy Dunlap said:

> +
> +24: All memory barriers {e.g., barrier(), rmb(), wmb()} need a comment in the
> +    source code that explains the logic of what they are doing and why.

"what they are doing" will almost always be "flush value to RAM" or similar.
How about this instead:

+ 24: All memory barriers ({e.g., barrier(), rmb(), wmb()} need a comment in the
+    source code that explains the race condition being prevented, and states
+    the location of the other code or hardware feature that races with this.
+
+    An example comment:
+
+ 	/*
+ 	 * If we don't do a wmb() here, the RBFROBNIZ register on the XU293
+ 	 * card will get confused and wedge the hardware...
+ 	 */
+	wmb();

Content of type "application/pgp-signature" skipped