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]

Message-Id: <1158041558.15465.77.camel@localhost.localdomain>
Date:	Tue, 12 Sep 2006 16:12:38 +1000
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Albert Cahalan <acahalan@...il.com>
Cc:	jbarnes@...tuousgeek.org, alan@...rguk.ukuu.org.uk,
	davem@...emloft.net, jeff@...zik.org, paulus@...ba.org,
	torvalds@...l.org, linux-kernel@...r.kernel.org, akpm@...l.org,
	segher@...nel.crashing.org
Subject: Re: Opinion on ordering of writel vs. stores to RAM

> Oops, I forgot about store-store ordering being automatic.
> Pretend I had some loads in my example.

Well, in 99% of the cases, you want MMIO loads to be orderd vs. MMIO
stores and thus you can use __writel and __readl (which will only do an
eieio in __readl). If you are really that picky, then, of course you can
go use the __raw_* versions.

> A proper interface would be more explicit about what the
> fence does, so that driver authors shouldn't need to know
> this detail.

What detail ? Isn't my document explicit enough ? If not, please let me
know what is not clear in the definition of the 4 ordering rules and the
matching fences.

> OK, a different discussion... though memory being used
> for DMA seems rather related. You need to flush before
> a DMA out, or invalidate before a DMA in.

This is already documented elsewhere.

> So you say: never mix strict mappings with loose operations,
> and never mix loose mappings with strict operations.

I don't want the concept of "lose mappings" in the generic driver
interface for now anyway :)

It's too implementation specific and I want to know that a given access
is strictly ordered or relaxed just by looking at the accessor used, not
having to go look for where the driver did the ioremap. We can still
provide arch specific things where we feel it's useful but let's move
one step at a time with the generic accessors.

The only "lose" mapping that we'll introduce next is write combining,
but that's also a different debate. Again, one thing at a time :)

> That is an excellent rule. I see no need to stop people from
> actively trying to shoot their feet though. I'm certainly not
> suggesting that people be mixing things.
> 
> For some CPUs, you want to be specifying things when you
> set up the mapping. For other CPUs, the read/write code is
> how this gets determined. So developers specify both.

For now, we are assuming that if the mapping controls ordering, then
it's strictly order. We'll see if we hit an arch where that becomes a
problem.

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/