[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <s5hiodxjnqs.wl-tiwai@suse.de>
Date: Thu, 19 Mar 2015 11:16:43 +0100
From: Takashi Iwai <tiwai@...e.de>
To: Andy Lutomirski <luto@...capital.net>
Cc: Jiri Kosina <jkosina@...e.cz>,
Denys Vlasenko <dvlasenk@...hat.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Stefan Seyfried <stefan.seyfried@...glemail.com>,
X86 ML <x86@...nel.org>, LKML <linux-kernel@...r.kernel.org>,
Tejun Heo <tj@...nel.org>
Subject: Re: PANIC: double fault, error_code: 0x0 in 4.0.0-rc3-2, kvm related?
Hi,
sorry to take time to back to this topic.
At Wed, 18 Mar 2015 15:29:14 -0700,
Andy Lutomirski wrote:
>
> On Wed, Mar 18, 2015 at 3:22 PM, Jiri Kosina <jkosina@...e.cz> wrote:
> > On Wed, 18 Mar 2015, Andy Lutomirski wrote:
> >
> >> sysret64 can only fail with #GP, and we're totally screwed if that
> >> happens,
> >
> > But what if the GPF handler pagefaults afterwards? It'd be operating on
> > user stack already.
>
> Good point.
>
> Stefan, can you try changing the first "jne
> opportunistic_sysret_failed" to "jmp opportunistic_sysret_failed" in
> entry_64.S and seeing if you can reproduce this? (Is it easy enough
> to reproduce that this would tell us anything?)
I tried this, and the same crash still happens.
On my machine (a Dell desktop with IvyBridge 4-core, 8GB RAM), I could
reproduce it relatively easily. Start a desktop session as usual, and
start a KVM with 1GB memory 4 CPU, and start compiling a kernel on VM
with make -j4. Meanwhile, start compiling a kernel with make -j8 on
the host, too. So nothing too special there. The kconfig is attached
below.
Currently I haven't set up kdump for this machine due to the disk
space. Will try to adjust somehow from now on.
Takashi
Download attachment ".config" of type "application/octet-stream" (109087 bytes)
Powered by blists - more mailing lists