linux-kernel - Re: [ANNOUNCE] mdb: Merkey's Linux Kernel Debugger 2.6.27-rc4 released

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:	Thu, 21 Aug 2008 14:03:26 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	paulmck@...ux.vnet.ibm.com
Cc:	Stefan Richter <stefanr@...6.in-berlin.de>,
	jmerkey@...fmountaingroup.com, linux-kernel@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Nick Piggin <nickpiggin@...oo.com.au>,
	David Howells <dhowells@...hat.com>
Subject: Re: [ANNOUNCE] mdb: Merkey's Linux Kernel Debugger 2.6.27-rc4
	released

On Thu, 2008-08-21 at 04:47 -0700, Paul E. McKenney wrote:
> On Thu, Aug 21, 2008 at 01:02:48PM +0200, Peter Zijlstra wrote:
> > On Thu, 2008-08-21 at 12:57 +0200, Stefan Richter wrote:
> > > Peter Zijlstra wrote:
> > > > On Wed, 2008-08-20 at 20:50 -0600, jmerkey@...fmountaingroup.com wrote:
> > > > 
> > > >>  volatiles left in the code due to the previously stated
> > > >>  (and still present) severe breakage of the GNU compiler with SMP 
> > > >>  shared data.  most of the barrier() functions are just plain broken
> > > >>  and do not result in proper compiler behavior in this tree. 
> > > > 
> > > > Can you provide explicit detail?
> > > > 
> > > > By using barrier() the compiler should clobber all its memory and
> > > > registers therefore forcing a write/reload of the variable.
> > > 
> > > I hope Jeff didn't try mere barrier()s only.  smp_wmb() and smp_rmb()
> > > are the more relevant barrier variants for mdb, from what I remember
> > > when I last looked at it.
> > 
> > Sure, but volatile isn't a replacement for memory barriers.
> 
> Let's face it, the C standard does not support concurrency, so we are
> all in a state of sin in any case, forced to rely on combinations of
> gcc-specific non-standard language extensions and assembly language.

Hehe, still, a little birdie told me they are working on it and perhaps
someone with clue could enlighten us on their direction.

Still, I'd like Jeff to show his C, the resulting asm and the intent for
the volatile and barrier versions of his code (well, little snippets of
his code obviuosly).

Either he doesn't understand barriers (nothing to be ashamed about), or
we might have more trouble lurking in the rest of the kernel.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/