netdev - RE: [PATCH] i386: Fix a couple busy loops in mach_wakecpu.h:wait_for_init

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: <NBBBIGEGHIGMPCNKHCECAEPEELAA.kenn@bluetree.ie>
Date:	Fri, 24 Aug 2007 13:12:54 +0100
From:	"Kenn Humborg" <kenn@...etree.ie>
To:	"Denys Vlasenko" <vda.linux@...glemail.com>,
	"Satyam Sharma" <satyam@...radead.org>
Cc:	"Heiko Carstens" <heiko.carstens@...ibm.com>,
	"Herbert Xu" <herbert@...dor.apana.org.au>,
	"Chris Snook" <csnook@...hat.com>, <clameter@....com>,
	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
	<linux-arch@...r.kernel.org>,
	"Linus Torvalds" <torvalds@...ux-foundation.org>,
	<netdev@...r.kernel.org>,
	"Andrew Morton" <akpm@...ux-foundation.org>, <ak@...e.de>,
	<davem@...emloft.net>, <schwidefsky@...ibm.com>,
	<wensong@...ux-vs.org>, <horms@...ge.net.au>,
	<wjiang@...ilience.com>, <cfriesen@...tel.com>, <zlynx@....org>,
	<rpjday@...dspring.com>, <jesper.juhl@...il.com>,
	<segher@...nel.crashing.org>
Subject: RE: [PATCH] i386: Fix a couple busy loops in mach_wakecpu.h:wait_for_init_deassert()

> On Thursday 16 August 2007 01:39, Satyam Sharma wrote:
> >
> >  static inline void wait_for_init_deassert(atomic_t *deassert)
> >  {
> > -	while (!atomic_read(deassert));
> > +	while (!atomic_read(deassert))
> > +		cpu_relax();
> >  	return;
> >  }
> 
> For less-than-briliant people like me, it's totally non-obvious that
> cpu_relax() is needed for correctness here, not just to make P4 happy.
> 
> IOW: "atomic_read" name quite unambiguously means "I will read
> this variable from main memory". Which is not true and creates
> potential for confusion and bugs.

To me, "atomic_read" means a read which is synchronized with other 
changes to the variable (using the atomic_XXX functions) in such 
a way that I will always only see the "before" or "after"
state of the variable - never an intermediate state while a 
modification is happening.  It doesn't imply that I have to 
see the "after" state immediately after another thread modifies
it.

Perhaps the Linux atomic_XXX functions work like that, or used
to work like that, but it's counter-intuitive to me that "atomic"
should imply a memory read.

Later,
Kenn

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html