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-next>] [day] [month] [year] [list]
Message-ID: <44F699CE.8050803@drzeus.cx>
Date:	Thu, 31 Aug 2006 10:11:58 +0200
From:	Pierre Ossman <drzeus-list@...eus.cx>
To:	LKML <linux-kernel@...r.kernel.org>
Subject: When to use mmiowb()?

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.

Any clarifications you can provide are very welcome. :)

Rgds
Pierre
-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ