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: <2486D031-097B-45C6-AC47-D8745844C5A3@kernel.crashing.org>
Date:	Mon, 11 Sep 2006 03:13:20 +0200
From:	Segher Boessenkool <segher@...nel.crashing.org>
To:	Jesse Barnes <jbarnes@...tuousgeek.org>
Cc:	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	David Miller <davem@...emloft.net>, jeff@...zik.org,
	paulus@...ba.org, torvalds@...l.org, linux-kernel@...r.kernel.org,
	akpm@...l.org
Subject: Re: Opinion on ordering of writel vs. stores to RAM

> Yeah, write combining is a good point.  After all these years we  
> *still*
> don't have a good in-kernel interface for changing memory mapped
> attributes, so adding a 'flags' argument to ioremap might be a good
> idea (cached, uncached, write combine are the three variants I can
> think of off the top of my head).

But what does "write-combine" mean?  There are many different
implementations of basically this same idea, and implementing
just the lowest common denominator of this will hardly get us
out of the mess we are in already.

>   - existing readX/writeX routines are defined to be strongly ordered
>   - new MMIO accessors are added with weak semantics (not sure I like
>     the __ naming though, driver authors will have to continually  
> refer
>     to documentation to figure out what they mean) along with new
>     barrier macros to synchronize things appropriately

What exactly will "weak" mean?  If it's weak enough to please all
architectures and busses, it'll be so weak that you'll need 2**N
(with a big N) different barriers.

>   - flags argument to ioremap

ioremap is a bad name anyway, if we'll change the API, change the
name as well (and it's a bad idea to keep the same name but make it
mean something different, anyway).

> Oh, and all MMIO accessors are *documented* with strongly defined
> semantics. :)

Not sure what this means?  Document them in all-caps?  :-)

> If we go this route though, can I request that we don't introduce any
> performance regressions in drivers currently using mmiowb()?  I.e.
> they'll be converted over to the new accessor routines when they  
> become
> available along with the new barrier macros?

In my proposal at least, those drivers won't lose any performance
(except for a conditional on their I/O cookie, which is a trivial
performance loss compared to the cost of the I/O /an sich/); they
won't need any changes either, except for some renaming.  Drivers
_not_ using it might get a performance loss though, because they
will be forced to run with every-I/O-ordered semantics; they will
suddenly start to work *correctly* though.

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/