linux-kernel - Re: [RFC] MMIO accessors & barriers documentation

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: <1158016731.15465.7.camel@localhost.localdomain>
Date:	Tue, 12 Sep 2006 09:18:51 +1000
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Roland Dreier <rdreier@...co.com>
Cc:	Jeff Garzik <jgarzik@...ox.com>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Linux Kernel list <linux-kernel@...r.kernel.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	"David S. Miller" <davem@...emloft.net>,
	Paul Mackerras <paulus@...ba.org>,
	Linus Torvalds <torvalds@...l.org>,
	Andrew Morton <akpm@...l.org>,
	Segher Boessenkool <segher@...nel.crashing.org>
Subject: Re: [RFC] MMIO accessors & barriers documentation


> where next_eqe_sw() checks a "valid" bit of a 32-byte event queue
> entry that is DMA-ed into memory by the device.  The device is careful
> to write the valid bit (byte actually) last, but on PowerPC 970
> without the rmb(), we actually saw the CPU reordering the read of
> eqe->type (which is another field of the EQ entry written by the
> device) so it happened before the entry was valid, but then executing
> the check of the valid bit far enough into the future so that the
> entry tested as valid.

Yes, the CPU can perfectly load it before the previous load, indeed. I'm
sure that wouldn't be powerpc specific. In this case, it would be a
speculative load (since there is a data dependency, thus you would think
it's ok, but it's not on CPUs that do speculative execution).

> This isn't that surprising: if you had two CPUs, with one CPU writing
> into a queue and the other CPU polling the queue, you would obviously
> need smp_rmb() on the CPU doing the reading.  But somehow it's not
> quite as obvious when a device plays the role of one of the CPUs.
> 
> Of course there's no MMIO anywhere in sight here, so this isn't
> directly applicable I guess.

It's a "normal" case memory barrier in this case. Same as for SMP. Yup. 

Ben.


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