linux-kernel - Re: Breakage caused by unreviewed patch in x86 tree

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:	Sun, 27 Apr 2008 19:03:59 -0400
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	Arjan van de Ven <arjan@...radead.org>
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, 2008-04-27 at 15:58 -0700, Arjan van de Ven wrote:
> 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".

My major complaint is the lack of review and notice, not the actual
patch.

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

Well, for certain device mailboxes, uncached does mean less performant.
The voyager breakage was exceptional ... I expect other problems just to
result in a loss of performance that caching gave by improving the
bursting.  If we're lucky, the PCI bridge cache might hide a lot of
this.

> 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 wouldn't have picked ... I'd have asked for input.

James


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