linux-kernel - 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-next>] [day] [month] [year] [list]

Message-Id: <1209329485.3801.46.camel@localhost.localdomain>
Date:	Sun, 27 Apr 2008 16:51:25 -0400
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>
Cc:	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Breakage caused by unreviewed patch in x86 tree

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.

I'm pissed off because it broke a class of voyager machines: those which
rely on the quad interrupt controller (QIC).  The precis of why they
broke is because the QIC does IPIs (or CPIs in its terminology) via
cache line interference: you interrupt a processor by moving a
designated memory area to write exclusive in the cache (by simply
writing to the line) and the CPU acks the interrupt by moving it back to
read shared (by reading from it).  That area, is, of course, mapped by
ioremap, so reversing the ioremap semantics and adding the uncached bit
completely breaks the QIC.  I might add that the intel SAPIC functions
in roughly the same manner, so this might break more than just voyager.

This patch was originally proposed my Matthew Wilcox in March 2006:

http://lkml.org/lkml/2006/3/30/251

And after a reasonable discussion, it was decided that there was too
much risk of breakage to take it.  How come you two decided that an
identical patch with different authorship could go in to your tree
without discussion this time?

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/