linux-kernel - Re: [patch] x86, voyager: fix ioremap

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: <20080427161415.5507a78b@laptopd505.fenrus.org>
Date:	Sun, 27 Apr 2008 16:14:15 -0700
From:	Arjan van de Ven <arjan@...radead.org>
To:	Jeff Garzik <jeff@...zik.org>
Cc:	"H. Peter Anvin" <hpa@...or.com>,
	David Miller <davem@...emloft.net>,
	James.Bottomley@...senPartnership.com, mingo@...e.hu,
	tglx@...utronix.de, linux-kernel@...r.kernel.org,
	torvalds@...ux-foundation.org
Subject: Re: [patch] x86, voyager: fix ioremap_nocache()

On Sun, 27 Apr 2008 19:02:05 -0400
Jeff Garzik <jeff@...zik.org> wrote:

> H. Peter Anvin wrote:
> > Jeff Garzik wrote:
> >>
> >> Understood.
> >>
> >> I guess I am more annoyed that this stealth semantics change
> >> appears to have broken everything that depends on pci_iomap(),
> >> including 90%+ of all libata drivers, unless I am missing
> >> something.
> >>
> >> That one piece of code (pci_iomap) was correct under the old 
> >> semantics, on x86 and elsewhere.  It's tested and working nicely,
> >> and depended upon by many drivers.
> >>
> > 
> > That one piece of code has had no effective change.  Under both the
> > old and the new code, both branches functionally because
> > ioremap_nocache(), in one case because of MTRR and in one case
> > because of PAT.
> 
> OK good...  libata uses it for controller registers exclusively, so
> that should be fine from an operational standpoint.
> 
> at the very least I 
> could have pointed out that lib/iomap.c wanted an update, and the 2.5
> yo discussion could have resurfaced.
> 

btw as a technical point: ioremap_cached() isn't guaranteed to give you cached memory.
In fact, on a PC, if you use ioremap_cached() on PCI bars, you will STILL get uncached
access, just because right now, it's not possible to give a cached mapping out!

We might want to try to change that in the future (by rewriting the MTRRs), but 
that would need a LOT of auditing of ioremap (ab)users to make sure they actually
mean "cached" when they ask for cached (pci_iomap... I'm not convinced it's users 
really can deal with cached) and it also will take a LOT of testing.



-- 
If you want to reach me at my work email, use arjan@...ux.intel.com
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org
--
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/