linux-kernel - Re: Opinion on ordering of writel vs. stores to RAM

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:	Mon, 11 Sep 2006 16:17:18 +0200
From:	Segher Boessenkool <segher@...nel.crashing.org>
To:	David Miller <davem@...emloft.net>
Cc:	jbarnes@...tuousgeek.org, jeff@...zik.org, paulus@...ba.org,
	torvalds@...l.org, linux-kernel@...r.kernel.org,
	benh@...nel.crashing.org, akpm@...l.org
Subject: Re: Opinion on ordering of writel vs. stores to RAM

>> Why not just keep writel() etc. for *both* purposes; the address  
>> cookie
>> it gets as input can distinguish between the required behaviours for
>> different kinds of I/Os; it will have to be setup by the arch- 
>> specific
>> __ioremap() or similar.
>
> This doesn't work when the I/O semantics are encoded into the
> instruction, not some virual mapping PTE bits.  We'll have to use
> a conditional or whatever in that case, which is silly.

Why is this "silly"?  Slowing down I/O accessors by a tiny little
bit isn't expensive, certainly not when compared to the cost of
having to do big-hammer synchronisation all over the place all the
time, like we need to do in the "all busses are strongly ordered
wrt to every other agent in the system" case.

Archs that _do_ implement only one set of ordering rules for every
bus, i.e. use the lowest common denominator on everything, do not
need such a conditional either of course -- only archs that want to
_gain_ performance.

There's plenty of other scenario's where such a conditional is
needed already btw, for example when some host bridges don't implement
PCI memory space as memory-mapped, but via an address+data register
(and yeah you can call such hardware "silly", and I certainly won't
disagree, but...)


Segher

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