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: <m1od7rkrmk.fsf@frodo.ebiederm.org>
Date:	Wed, 30 Apr 2008 13:35:47 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	David Miller <davem@...emloft.net>, jeff@...zik.org,
	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()

"H. Peter Anvin" <hpa@...or.com> writes:

> David Miller wrote:
>> I think this is a reasonable course of action.
>>
>> That leaves one of Jeff's concerns, what to do with pci_iomap().  That
>> was designed to give mappings with caching enabled, and as a result we
>> probably should make it behave that way.
>
> Yes, it should.  Just be clear that *that* is a semantic change over what the
> code currently does; it would appear that that is what the code is *trying* to
> do.
>
> I believe on x86 it will still get clamped by the MTRRs, at least initially (I
> don't think we have flipped the default MTRR type to WB yet) but that would
> immediately change the behaviour on non-x86 architectures.

Flipping the default MTRR type to WB has the potential to break an SMM
monitor which does I/O and isn't using our page tables.  So we need to
be very careful about that direction.  Finally I remember what
the specific and really scary failure mode with SMM and mucking with
the MTRRs is.

There don't appear to be many bars that set IORESOURCE_CACHABLE for use
with pci_iomap so it doesn't appear to be much of an issue.

In addition it looks like we should map IORESOURCE_PREFETCH to ioremap_wc
in pci_iomap, for those places that can take advantage of it.  It
might not always work (hardware is like that) but semantically pci
prefetch is the same as the WC attribute (reads and writes have no
side effects).  I believe on x86 if we want to get cacheline sized
reads (read prefetch) there is special instruction in the latest
processors we need to use on a wc area.

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