Message-Id: <45D0422A.76E4.0078.0@novell.com>
Date: Mon, 12 Feb 2007 09:32:10 +0000
From: "Jan Beulich" <jbeulich@novell.com>
To: "Jeff Dike" <jdike@addtoit.com>, "Andi Kleen" <ak@suse.de>
Cc: <linux-kernel@vger.kernel.org>, <patches@x86-64.org>
Subject: Re: [patches] [PATCH 2.6.21 review I] [4/25] x86: kernel-mode
	faults pollute current->thead
References: <200702101250.142420000@suse.de>
 <20070210115016.652C913DCE@wotan.suse.de>
In-Reply-To: <20070210115016.652C913DCE@wotan.suse.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1966
Lines: 45

>>> Andi Kleen <ak@suse.de> 10.02.07 12:50 >>>
>
>From: Jeff Dike <jdike@addtoit.com>
>
>Kernel-mode traps on x86_64 can pollute the trap information for a previous
>userspace trap for which the signal has not yet been delivered to the
>process.
>
>do_trap and do_general_protection set task->thread.error_code and .trapno
>for kernel traps.  If a kernel-mode trap arrives between the arrival of a
>userspace trap and the delivery of the associated SISGEGV to the process,
>the process will get the kernel trap information in its sigcontext.
>
>This causes UML process segfaults, as the trapno that the UML kernel sees
>is 13, rather than the 14 for normal page faults.  So, the UML kernel
>passes the SIGSEGV along to its process.
>
>I don't claim to fully understand the problem.  On the one hand, a check in
>do_general_protection for a pending SIGSEGV turned up nothing.  On the
>other hand, this patch fixed the UML process segfault problem.
>
>The patch below moves the setting of error_code and trapno so that that
>only happens in the case of userspace faults.  As a side-effect, this
>should speed up kernel-mode fault handling a tiny bit.

This breaks consumers of notify_die() relying on the proper trap number being
passed, as the call to notify_die() from die() currently reads
current->thread.trap_no.

Also, you seem to leave other places where trap_no gets set untouched -
is this intentional (do_debug - probably correct here, kernel_math_error -
probably incorrect here)?

>I looked at i386, and there is a similar situation.  In this case, there is
>duplicate code setting task->thread.error_code and trapno.  I deleted one,
>leaving the copy that runs in the case of a userspace fault.

Likewise.

Jan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/