linux-kernel - Re: [ANNOUNCE] Merkey's Kernel Debugger

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, 07 Aug 2008 19:04:32 +0200
From:	Stefan Richter <stefanr@...6.in-berlin.de>
To:	jmerkey@...fmountaingroup.com
CC:	Andi Kleen <andi@...stfloor.org>,
	Jason Wessel <jason.wessel@...driver.com>,
	Nick Piggin <nickpiggin@...oo.com.au>,
	Geert Uytterhoeven <geert@...ux-m68k.org>,
	Josh Boyer <jwboyer@...il.com>, linux-kernel@...r.kernel.org
Subject: Re: [ANNOUNCE] Merkey's Kernel Debugger

jmerkey@...fmountaingroup.com wrote:
>>> Also, whoever wrote "/Documentation/volatiles_are_evil" must not have
>>> worked with the busted-ass GNU compiler that optimizes away global
>>> variables and busts SMP dependent code.  I am not going to remove the
>> The Linux way to handle this is to use gcc memory barriers.
>> mb()/barrier()/wmb()/rmb()/smp_rmb()/smp_wmb() etc.
>> Normally everything that volatile can do can be expressed by them.
[...]
>> See Documentation/memory-barriers.txt
[...]
> I'll instrument this as described in the documentation you referenced and
> remove the volatile declarations.  If this passes testing, I will repost
> with these corections.

Take care though that neither memory barriers nor volatile are what you 
want if accesses need to be atomic on whatever given data structure. 
(E.g. bitfield manipulations, counter increments, accesses to virtually 
anything that is bigger than an integer or a pointer...)
-- 
Stefan Richter
-=====-==--- =--- --===
http://arcgraph.de/sr/
--
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/