linux-kernel - Re: When to use mmiowb()?

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] [day] [month] [year] [list]

Message-ID: <17655.10081.79181.750626@base.ty.sabi.co.UK>
Date:	Thu, 31 Aug 2006 19:16:01 +0100
From:	pg_lkm@....for.sabi.co.UK (Peter Grandi)
To:	Linux kernel <linux-kernel@...r.kernel.org>
Subject: Re: When to use mmiowb()?

>>> On Thu, 31 Aug 2006 10:11:58 +0200, Pierre Ossman
>>> <drzeus-list@...eus.cx> said:

drzeus-list> I'm been trying to wrap my head around all this
drzeus-list> memory barrier business, and I'm slowly grasping
drzeus-list> the inter-CPU behaviours. Barriers with regard to
drzeus-list> devices still has me a bit confused though. [ ... ] 
drzeus-list> This leads me to believe that memory-barriers.txt
drzeus-list> is closer to the truth, but then the question is
drzeus-list> what those special cirumstances that require
drzeus-list> mmiowb() are.

I have just been staring at a new driver which containts (more
or less these lines:

------------------------------------------------------------------------
#if !(defined CONFIG_ARCH_IA64_SN2 || defined CONFIG_ARCH_IA64_GENERIC)
#define mmiowb()		((void) 0)
#endif
------------------------------------------------------------------------

Very funny, isn't it? :-)

Now the story is that there is not one truth, but several. About
as many as there are platforms and configurations.

On most popular platforms and most configurations 'mmiowb' is
not necessary, so people don't bother and ''it works''. On a few
platforms and configurations it matters, so people using them do
apply it rather more extensively.

In theory it should be used everywhere there is a sequence
hazard, but that's an itch that only a minority needs to
scratch.

Free (and commercial) software is based on the ''social''
definition of ''works'', perhaps regrettably, which means that
if enough people don't see errors, the errors don't ''exist''.

Then there are forward looking people like Linus who was using
an Alpha to develop the kernel (and more recently a G5 IIRC)
precisely to create for himself itches to scratch, triggered by
configurations that the overwhelming majority of x86 users would
not see...

BTW, in a related issue Linus has said that one of the big
problems with kernel development is that a lot of people just
don't get race conditions (which are an intrinsically hard
subject anyhow), and that this has influenced his overall kernel
design.
-
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/