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:	Tue, 12 Sep 2006 03:09:46 -0400
From:	"Albert Cahalan" <acahalan@...il.com>
To:	"Benjamin Herrenschmidt" <benh@...nel.crashing.org>
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

On 9/12/06, Benjamin Herrenschmidt <benh@...nel.crashing.org> wrote:
>
> > 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.

If I could get the __raw_* versions for every arch, and there
wouldn't be any endianness troubles, it'd do.

I think a single or double "_" is enough warning to enable
full foot-shooting ability though.

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

The driver code is not very self-documenting this way.

If I see an io_to_io_barrier(), how am I to tell if it is
read to read, write to write, read to write, write to read,
read/write to read, read/write to write, read to read/write,
write to read/write, or read/write to read/write?

Considering just reads and writes to MMIO, there are
9 possible types of fence. SPARC seems to cover a
decent number of these distinctly; the instruction takes
an immediate value as flags.

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

I suppose the "sparse" tool could match up mapping type
with accessor type. That'd let you rely on the accessor to
be doing what you expect when you read the code.

Loose mappings are only arch-specific in implementation.
Generic non-arch driver code ought to be able to take
advantage of the performance benefits of loose mappings.
(that is: full any-any reordering)
-
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/