[Top] [All Lists]

Re: [GIT PULL] x86/mm changes for v3.9-rc1

To: Linus Torvalds <>
Subject: Re: [GIT PULL] x86/mm changes for v3.9-rc1
From: "H. Peter Anvin" <>
Date: Fri, 22 Feb 2013 09:31:27 -0800
Cc: "H. Peter Anvin" <>, "David S. Miller" <>, "Rafael J. Wysocki" <>, stable <>, Alexander Duyck <>, Andrea Arcangeli <>, Andrew Morton <>, Andrzej Pietrasiewicz <>, Arnd Bergmann <>, Borislav Petkov <>, Borislav Petkov <>, Christoph Lameter <>, Daniel J Blueman <>, Dave Hansen <>, "Eric W. Biederman" <>, Fenghua Yu <>, Frederic Weisbecker <>, Gleb Natapov <>, Gokul Caushik <>, "H. J. Lu" <>, Hugh Dickins <>, Ingo Molnar <>, Ingo Molnar <>, Jacob Shin <>, Jamie Lokier <>, Jarkko Sakkinen <>, Jeremy Fitzhardinge <>, Joe Millenbach <>, Joerg Roedel <>, Johannes Weiner <>, Josh Triplett <>, Konrad Rzeszutek Wilk <>, Kyungmin Park <>, Lee Schermerhorn <>, Len Brown <>, Linux Kernel Mailing List <>, Marcelo Tosatti <>, Marek Szyprowski <>, Matt Fleming <>, Mel Gorman <>, Paul Turner <>, Pavel Machek <>, Pekka Enberg <>, Peter Zijlstra <>, Ralf Baechle <>, Rik van Riel <>, Rob Landley <>, Russell King <>, Rusty Russell <>, Shuah Khan <>, Shuah Khan <>, Stefano Stabellini <>, Steven Rostedt <>, Thomas Gleixner <>, Ville Syrjälä <>, Yasuaki Ishimatsu <>, Yinghai Lu <>, Zachary Amsden <>, Avi Kivity <>, linux-mips <>, "" <>, "Michael S. Tsirkin" <>,, virtualization <>, "" <>
In-reply-to: <>
List-archive: <>
List-help: <>
List-id: linux-mips <>
List-owner: <>
List-post: <>
List-software: Ecartis version 1.0.0
List-subscribe: <>
List-unsubscribe: <>
References: <> <>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2
On 02/22/2013 08:22 AM, Linus Torvalds wrote:

Ugh. So I've tried to walk through this, and it's painful. If this
results in problems, we're going to be *so* screwed. Is it bisectable?

I can't tell you for sure that it is bisectable at every point. There are definite bisection points in there, though, as this is several pieces of work from two kernel cycles that were independently tested.

I also don't understand how "early_idt_handler" could *possibly* work.
In particular, it seems to rely on the trap number being set up in the
stack frame:

         cmpl $14,72(%rsp)       # Page fault?

but that's not even *true*. Why? Because we export both the
early_idt_handlers[] array (that sets up the trap number and makes the
stack frame be reliable) and the single early_idt_handler function
(that relies on the trap number and the reliable stack frame), AND

See x86_64_start_kernel():

         for (i = 0; i < NUM_EXCEPTION_VECTORS; i++) {
                 set_intr_gate(i, &early_idt_handlers[i]);
                 set_intr_gate(i, early_idt_handler);

so unless you have CONFIG_EARLY_PRINTK, the interrupt gate will point
to that raw early_idt_handler function that doesn't *work* on its own,

This is a (pre-existing!) bug that absolutely needs to be fixed, which ought to break other things too (early use of *msr_safe for example, or anything else that relies on an early exception entry, which there aren't a lot of so far). The fix is simple and obvious.
But you're right... what the heck is going on here?

My own testing would probably not have caught this, as I consider EARLY_PRINTK a must have, but Ingo's test machines definitely would have.

Btw, it's not just the page fault index testing that is wrong. The whole

         cmpl $__KERNEL_CS,96(%rsp)
         jne 11f

also relies on the stack frame being set up the same way for all
exceptions - which again is only true if we ran through the
early_idt_handlers[] prologue that added the extra stack entry.

How does this even work for me? I don't have EARLY_PRINTK enabled.

What am I missing?

I just ran a simulation without EARLY_PRINTK, presumably based on the memory layout, we can apparently go through the entire bootup sequence without actually ever taking an early trap. It is a bug, though, and it is a bug even without this patchset. I will submit a fix. However, the Xen "we tested this, this worked, now it doesn't" worries me a lot.


H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

<Prev in Thread] Current Thread [Next in Thread>