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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sun, 27 Apr 2008 15:58:03 -0700
From:	Arjan van de Ven <arjan@...radead.org>
To:	James Bottomley <James.Bottomley@...senPartnership.com>
Cc:	Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: Breakage caused by unreviewed patch in x86 tree

On Sun, 27 Apr 2008 16:51:25 -0400
James Bottomley <James.Bottomley@...senPartnership.com> wrote:

> This patch:
> 
> commit 6371b495991debfd1417b17c2bc4f7d7bae05739
> Author: Ingo Molnar <mingo@...e.hu>
> Date:   Wed Jan 30 13:33:40 2008 +0100
> 
>     x86: change ioremap() to default to uncached
> 
> As far as I can tell went blindly into the x86 tree without being
> shared on any mailing list at all.  How can something that completely
> alters the semantics of ioremap on x86 platforms go in without any
> review.

it changed from "whatever coinflip you got" to "predictable outcome". 
What you got before was uncached (most of the time), or if the bios was
creative, write combining. Or if the bios was broken in how it set up MTRR's, you could suddenly
get "cached".

When you're mapping device memory, uncached is the safe default. 

With the switch to PAT (and phasing out of MTRR), the kernel needs to pick one of the three
(cached, writecombining, uncached) since you can no longer really depend on MTRRs saving
your bacon there. 
Drivers in general, with VERY few exceptions, want uncached. Any other choice would have been deadly...

I'd like to ask you which one you would pick... you maintain a whole bunch of drivers as scsi maintainer, what would
you have picked?
The answer "whatever the MTRR set up" no longer holds ;(

> 
>  I might add that the intel
> SAPIC functions in roughly the same manner, so this might break more
> than just voyager.

Apics are uncached...


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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ