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

Message-Id: <200608310931.37617.jesse.barnes@intel.com>
Date:	Thu, 31 Aug 2006 09:31:37 -0700
From:	Jesse Barnes <jesse.barnes@...el.com>
To:	Pierre Ossman <drzeus-list@...eus.cx>
Cc:	LKML <linux-kernel@...r.kernel.org>
Subject: Re: When to use mmiowb()?

On Thursday, August 31, 2006 1:11 am, Pierre Ossman wrote:
> I'm been trying to wrap my head around all this memory barrier
> business, and I'm slowly grasping the inter-CPU behaviours. Barriers
> with regard to devices still has me a bit confused though.
>
> The deviceiobook document and memory-barriers.txt both make it clear
> that memory operations to devices are strictly ordered from a single
> CPU. When more CPUs are involved, things get a bit fuzzier.
> memory-barriers.txt seems to suggest that mmiowb() is only needed
> before an unlock under special circumstances, but deviceiobook states
> that mmiowb() should be used before all unlocks where the writeX():s
> aren't followed by a readX() (which would flush the writes anyway).
>
> Grepping the tree indicates that mmiowb() isn't used that often, but
> according to deviceiobook, they should be plentiful. This leads me to
> believe that memory-barriers.txt is closer to the truth, but then the
> question is what those special cirumstances that require mmiowb() are.

AFAICT, they're both right.  Generally, mmiowb() should be used prior to 
unlock in a critical section whose last PIO operation is a writeX.

You're right though: for portability, many more drivers should use this 
type of barrier.  However, rather than doing an audit of the tree and 
inserting mmiowb() everywhere (w/o testing it), we chose to add it on an 
as-needed basis for drivers that run on platforms that have weak I/O 
ordering.  Feel free to add it in other places if you want though (esp. 
if you have the hardware to test your changes).

Jesse
-
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/