Date: Thu, 28 Oct 2004 01:27:15 +0200
From: Andi Kleen <ak@suse.de>
To: Chris Wright <chrisw@osdl.org>
Cc: ak@suse.de, linux-kernel@vger.kernel.org
Subject: Re: Early call_usermodehelper causes double fault on x86_64
Message-ID: <20041027232715.GE23595@wotan.suse.de>
References: <20041027124055.B2357@build.pdx.osdl.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20041027124055.B2357@build.pdx.osdl.net>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1160
Lines: 25

On Wed, Oct 27, 2004 at 12:40:55PM -0700, Chris Wright wrote:
> Hi,
> 
> I'm seeing a double fault on recent (2.6.10-rc1-bk) kernels during
> driver_init().  The upcall to userspace gets far enough to schedule the
> work, khelper picks it up, calls kernel_thread, the child thread does
> execve, then double faults.  Bootup continues, I get three more double
> faults, then the system appears fine (even w/ continued upcalls).
> 
> I have an example of the fault below.  It shows a rip and rsp
> of 0.  I poked about a bit and see that the FAKE_STACK_FRAME $0 in
> arch/x86-64/kernel/entry.S sets up a 0 rip, and if I change the \rip
> in that macro call, that's the rip in the double fault.  Any ideas on
> further debugging?

It looks like do_execve returned with a zero return without
executing start_thread properly. I would add a printk to 
all error exits in the execve path and see which one triggers.

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