On Wed, 18 Mar 2015, Andy Lutomirski wrote:
> > I posted the same problem to the opensuse kernel list shortly before turning
> > to LKML. There, Michal Kubecek noted:
> >
> > "I encountered a similar problem recently. The thing is, x86
> > specification says that on a double fault, RIP and RSP
On Wed, 18 Mar 2015, Andy Lutomirski wrote:
I posted the same problem to the opensuse kernel list shortly before turning
to LKML. There, Michal Kubecek noted:
I encountered a similar problem recently. The thing is, x86
specification says that on a double fault, RIP and RSP registers are
On Mon, Mar 23, 2015 at 12:07 PM, Denys Vlasenko wrote:
> On 03/23/2015 07:38 PM, Andy Lutomirski wrote:
>>> cmpq $__NR_syscall_max,%rax
>>> ja ret_from_sys_call
>>> movq %r10,%rcx
>>> call *sys_call_table(,%rax,8) # XXX:rip relative
>>> movq
On 03/23/2015 07:38 PM, Andy Lutomirski wrote:
>> cmpq $__NR_syscall_max,%rax
>> ja ret_from_sys_call
>> movq %r10,%rcx
>> call *sys_call_table(,%rax,8) # XXX:rip relative
>> movq %rax,RAX-ARGOFFSET(%rsp)
>> ret_from_sys_call:
>> testl
At Mon, 23 Mar 2015 11:48:42 -0700,
Andy Lutomirski wrote:
>
> On Mon, Mar 23, 2015 at 11:38 AM, Andy Lutomirski wrote:
> > On Mon, Mar 23, 2015 at 9:07 AM, Denys Vlasenko wrote:
> >> On 03/23/2015 02:22 PM, Takashi Iwai wrote:
> >>> At Mon, 23 Mar 2015 10:35:41 +0100,
> >>> Takashi Iwai wrote:
At Mon, 23 Mar 2015 11:38:30 -0700,
Andy Lutomirski wrote:
>
> On Mon, Mar 23, 2015 at 9:07 AM, Denys Vlasenko wrote:
> > On 03/23/2015 02:22 PM, Takashi Iwai wrote:
> >> At Mon, 23 Mar 2015 10:35:41 +0100,
> >> Takashi Iwai wrote:
> >>>
> >>> At Mon, 23 Mar 2015 10:02:52 +0100,
> >>> Takashi
Am 23.03.2015 um 19:38 schrieb Andy Lutomirski:
> I bet I see it. I have the advantage of having stared at KVM code and
> cursed at it more recently than you, I suspect. KVM does awful, awful
> things to CPU state, and, as an optimization, it allows kernel code to
> run with CPU state that would
On Mon, Mar 23, 2015 at 11:38 AM, Andy Lutomirski wrote:
> On Mon, Mar 23, 2015 at 9:07 AM, Denys Vlasenko wrote:
>> On 03/23/2015 02:22 PM, Takashi Iwai wrote:
>>> At Mon, 23 Mar 2015 10:35:41 +0100,
>>> Takashi Iwai wrote:
At Mon, 23 Mar 2015 10:02:52 +0100,
Takashi Iwai wrote:
At Mon, 23 Mar 2015 18:46:45 +0100,
Denys Vlasenko wrote:
>
> On 03/23/2015 06:18 PM, Takashi Iwai wrote:
> > At Mon, 23 Mar 2015 17:07:15 +0100, Denys Vlasenko wrote:
> I pulled tip tree on top of 4.0-rc5, built with your patch and now
> succeeded to get a better message:
>
>
On Mon, Mar 23, 2015 at 9:07 AM, Denys Vlasenko wrote:
> On 03/23/2015 02:22 PM, Takashi Iwai wrote:
>> At Mon, 23 Mar 2015 10:35:41 +0100,
>> Takashi Iwai wrote:
>>>
>>> At Mon, 23 Mar 2015 10:02:52 +0100,
>>> Takashi Iwai wrote:
At Fri, 20 Mar 2015 19:16:53 +0100,
Denys Vlasenko
On 03/23/2015 06:18 PM, Takashi Iwai wrote:
> At Mon, 23 Mar 2015 17:07:15 +0100, Denys Vlasenko wrote:
I pulled tip tree on top of 4.0-rc5, built with your patch and now
succeeded to get a better message:
kvm: zapping shadow pages for mmio generation wraparound
kvm
At Mon, 23 Mar 2015 17:07:15 +0100,
Denys Vlasenko wrote:
>
> On 03/23/2015 02:22 PM, Takashi Iwai wrote:
> > At Mon, 23 Mar 2015 10:35:41 +0100,
> > Takashi Iwai wrote:
> >>
> >> At Mon, 23 Mar 2015 10:02:52 +0100,
> >> Takashi Iwai wrote:
> >>>
> >>> At Fri, 20 Mar 2015 19:16:53 +0100,
> >>>
On 03/23/2015 02:22 PM, Takashi Iwai wrote:
> At Mon, 23 Mar 2015 10:35:41 +0100,
> Takashi Iwai wrote:
>>
>> At Mon, 23 Mar 2015 10:02:52 +0100,
>> Takashi Iwai wrote:
>>>
>>> At Fri, 20 Mar 2015 19:16:53 +0100,
>>> Denys Vlasenko wrote:
Takashi, are you willing to reproduce the panic one
At Mon, 23 Mar 2015 10:35:41 +0100,
Takashi Iwai wrote:
>
> At Mon, 23 Mar 2015 10:02:52 +0100,
> Takashi Iwai wrote:
> >
> > At Fri, 20 Mar 2015 19:16:53 +0100,
> > Denys Vlasenko wrote:
> > > Takashi, are you willing to reproduce the panic one more time,
> > > with this patch? I would like to
At Mon, 23 Mar 2015 10:02:52 +0100,
Takashi Iwai wrote:
>
> At Fri, 20 Mar 2015 19:16:53 +0100,
> Denys Vlasenko wrote:
> > Takashi, are you willing to reproduce the panic one more time,
> > with this patch? I would like to see whether oops messages
> > are more informative with it.
>
> It can't
At Fri, 20 Mar 2015 19:16:53 +0100,
Denys Vlasenko wrote:
>
> Hi,
>
> This particular crash was hard to diagnose because of two reasons:
>
> * CPU would happily use userspace RSP in kernel mode.
> Crash comes only later, when we run off the stack.
> We lose information when it started.
>
>
At Mon, 23 Mar 2015 10:35:41 +0100,
Takashi Iwai wrote:
At Mon, 23 Mar 2015 10:02:52 +0100,
Takashi Iwai wrote:
At Fri, 20 Mar 2015 19:16:53 +0100,
Denys Vlasenko wrote:
Takashi, are you willing to reproduce the panic one more time,
with this patch? I would like to see whether
At Mon, 23 Mar 2015 10:02:52 +0100,
Takashi Iwai wrote:
At Fri, 20 Mar 2015 19:16:53 +0100,
Denys Vlasenko wrote:
Takashi, are you willing to reproduce the panic one more time,
with this patch? I would like to see whether oops messages
are more informative with it.
It can't be applied
On 03/23/2015 02:22 PM, Takashi Iwai wrote:
At Mon, 23 Mar 2015 10:35:41 +0100,
Takashi Iwai wrote:
At Mon, 23 Mar 2015 10:02:52 +0100,
Takashi Iwai wrote:
At Fri, 20 Mar 2015 19:16:53 +0100,
Denys Vlasenko wrote:
Takashi, are you willing to reproduce the panic one more time,
with this
On 03/23/2015 07:38 PM, Andy Lutomirski wrote:
cmpq $__NR_syscall_max,%rax
ja ret_from_sys_call
movq %r10,%rcx
call *sys_call_table(,%rax,8) # XXX:rip relative
movq %rax,RAX-ARGOFFSET(%rsp)
ret_from_sys_call:
testl
On Mon, Mar 23, 2015 at 12:07 PM, Denys Vlasenko dvlas...@redhat.com wrote:
On 03/23/2015 07:38 PM, Andy Lutomirski wrote:
cmpq $__NR_syscall_max,%rax
ja ret_from_sys_call
movq %r10,%rcx
call *sys_call_table(,%rax,8) # XXX:rip relative
movq
At Fri, 20 Mar 2015 19:16:53 +0100,
Denys Vlasenko wrote:
Hi,
This particular crash was hard to diagnose because of two reasons:
* CPU would happily use userspace RSP in kernel mode.
Crash comes only later, when we run off the stack.
We lose information when it started.
*
At Mon, 23 Mar 2015 17:07:15 +0100,
Denys Vlasenko wrote:
On 03/23/2015 02:22 PM, Takashi Iwai wrote:
At Mon, 23 Mar 2015 10:35:41 +0100,
Takashi Iwai wrote:
At Mon, 23 Mar 2015 10:02:52 +0100,
Takashi Iwai wrote:
At Fri, 20 Mar 2015 19:16:53 +0100,
Denys Vlasenko wrote:
Am 23.03.2015 um 19:38 schrieb Andy Lutomirski:
I bet I see it. I have the advantage of having stared at KVM code and
cursed at it more recently than you, I suspect. KVM does awful, awful
things to CPU state, and, as an optimization, it allows kernel code to
run with CPU state that would be
At Mon, 23 Mar 2015 11:48:42 -0700,
Andy Lutomirski wrote:
On Mon, Mar 23, 2015 at 11:38 AM, Andy Lutomirski l...@amacapital.net wrote:
On Mon, Mar 23, 2015 at 9:07 AM, Denys Vlasenko dvlas...@redhat.com wrote:
On 03/23/2015 02:22 PM, Takashi Iwai wrote:
At Mon, 23 Mar 2015 10:35:41
At Mon, 23 Mar 2015 18:46:45 +0100,
Denys Vlasenko wrote:
On 03/23/2015 06:18 PM, Takashi Iwai wrote:
At Mon, 23 Mar 2015 17:07:15 +0100, Denys Vlasenko wrote:
I pulled tip tree on top of 4.0-rc5, built with your patch and now
succeeded to get a better message:
kvm: zapping shadow
On 03/23/2015 06:18 PM, Takashi Iwai wrote:
At Mon, 23 Mar 2015 17:07:15 +0100, Denys Vlasenko wrote:
I pulled tip tree on top of 4.0-rc5, built with your patch and now
succeeded to get a better message:
kvm: zapping shadow pages for mmio generation wraparound
kvm [5126]: vcpu0 disabled
On Mon, Mar 23, 2015 at 9:07 AM, Denys Vlasenko dvlas...@redhat.com wrote:
On 03/23/2015 02:22 PM, Takashi Iwai wrote:
At Mon, 23 Mar 2015 10:35:41 +0100,
Takashi Iwai wrote:
At Mon, 23 Mar 2015 10:02:52 +0100,
Takashi Iwai wrote:
At Fri, 20 Mar 2015 19:16:53 +0100,
Denys Vlasenko wrote:
On Mon, Mar 23, 2015 at 11:38 AM, Andy Lutomirski l...@amacapital.net wrote:
On Mon, Mar 23, 2015 at 9:07 AM, Denys Vlasenko dvlas...@redhat.com wrote:
On 03/23/2015 02:22 PM, Takashi Iwai wrote:
At Mon, 23 Mar 2015 10:35:41 +0100,
Takashi Iwai wrote:
At Mon, 23 Mar 2015 10:02:52 +0100,
At Mon, 23 Mar 2015 11:38:30 -0700,
Andy Lutomirski wrote:
On Mon, Mar 23, 2015 at 9:07 AM, Denys Vlasenko dvlas...@redhat.com wrote:
On 03/23/2015 02:22 PM, Takashi Iwai wrote:
At Mon, 23 Mar 2015 10:35:41 +0100,
Takashi Iwai wrote:
At Mon, 23 Mar 2015 10:02:52 +0100,
Takashi Iwai
At Fri, 20 Mar 2015 19:16:53 +0100,
Denys Vlasenko wrote:
>
> Takashi, are you willing to reproduce the panic one more time,
> with this patch? I would like to see whether oops messages
> are more informative with it.
Sure, I'll do it, but you'll have to wait until the next Monday as the
bug is
Hi,
This particular crash was hard to diagnose because of two reasons:
* CPU would happily use userspace RSP in kernel mode.
Crash comes only later, when we run off the stack.
We lose information when it started.
* Kernel's error handling code is ill prepared for RSP pointing
to user
At Fri, 20 Mar 2015 19:16:53 +0100,
Denys Vlasenko wrote:
Takashi, are you willing to reproduce the panic one more time,
with this patch? I would like to see whether oops messages
are more informative with it.
Sure, I'll do it, but you'll have to wait until the next Monday as the
bug is
Hi,
This particular crash was hard to diagnose because of two reasons:
* CPU would happily use userspace RSP in kernel mode.
Crash comes only later, when we run off the stack.
We lose information when it started.
* Kernel's error handling code is ill prepared for RSP pointing
to user
On Thu, Mar 19, 2015 at 8:51 AM, Takashi Iwai wrote:
> At Thu, 19 Mar 2015 08:41:57 -0700,
> Andy Lutomirski wrote:
>>
>> On Thu, Mar 19, 2015 at 8:22 AM, Takashi Iwai wrote:
>> > At Thu, 19 Mar 2015 15:55:26 +0100,
>> > Takashi Iwai wrote:
>> >>
>> >> At Thu, 19 Mar 2015 14:47:12 +0100,
>> >>
At Thu, 19 Mar 2015 08:41:57 -0700,
Andy Lutomirski wrote:
>
> On Thu, Mar 19, 2015 at 8:22 AM, Takashi Iwai wrote:
> > At Thu, 19 Mar 2015 15:55:26 +0100,
> > Takashi Iwai wrote:
> >>
> >> At Thu, 19 Mar 2015 14:47:12 +0100,
> >> Takashi Iwai wrote:
> >> >
> >> > At Thu, 19 Mar 2015 13:48:56
On Thu, Mar 19, 2015 at 8:22 AM, Takashi Iwai wrote:
> At Thu, 19 Mar 2015 15:55:26 +0100,
> Takashi Iwai wrote:
>>
>> At Thu, 19 Mar 2015 14:47:12 +0100,
>> Takashi Iwai wrote:
>> >
>> > At Thu, 19 Mar 2015 13:48:56 +0100,
>> > Denys Vlasenko wrote:
>> > >
>> > > Having no more ideas at the
At Thu, 19 Mar 2015 15:55:26 +0100,
Takashi Iwai wrote:
>
> At Thu, 19 Mar 2015 14:47:12 +0100,
> Takashi Iwai wrote:
> >
> > At Thu, 19 Mar 2015 13:48:56 +0100,
> > Denys Vlasenko wrote:
> > >
> > > Having no more ideas at the moment, here is a tarball of 13 patches
> > > of commits touching
At Thu, 19 Mar 2015 14:47:12 +0100,
Takashi Iwai wrote:
>
> At Thu, 19 Mar 2015 13:48:56 +0100,
> Denys Vlasenko wrote:
> >
> > Having no more ideas at the moment, here is a tarball of 13 patches
> > of commits touching entry_64.S up to 4.0.0-rc1.
> >
> > x0001.patch is the latest, x0015.patch
At Thu, 19 Mar 2015 13:48:56 +0100,
Denys Vlasenko wrote:
>
> Having no more ideas at the moment, here is a tarball of 13 patches
> of commits touching entry_64.S up to 4.0.0-rc1.
>
> x0001.patch is the latest, x0015.patch is the oldest.
>
> Patches 0003 and 0008 are not there since 0003 is
On 03/18/2015 10:55 PM, Andy Lutomirski wrote:
> On Wed, Mar 18, 2015 at 2:42 PM, Denys Vlasenko wrote:
>>> in 'irq_return_via_sysret' is new to 4.0, and instead of entering the
>>> kernel with a user stack poiinter, maybe we're *exiting* the kernel,
>>> and have just reloaded the user stack
Having no more ideas at the moment, here is a tarball of 13 patches
of commits touching entry_64.S up to 4.0.0-rc1.
x0001.patch is the latest, x0015.patch is the oldest.
Patches 0003 and 0008 are not there since 0003 is empty merge patch
and 0008 does some PCI fixup.
If this breakage is recent,
At Thu, 19 Mar 2015 11:58:19 +0100,
Denys Vlasenko wrote:
>
> On 03/19/2015 11:16 AM, Takashi Iwai wrote:
> > The kconfig is attached
>
> You also have PARAVIRT enabled, like Stefan.
>
> Just to obtain an additional data point, can you guys
> try reproducing it with PARAVIRT off?
>
> It won't
On 03/19/2015 11:16 AM, Takashi Iwai wrote:
> The kconfig is attached
You also have PARAVIRT enabled, like Stefan.
Just to obtain an additional data point, can you guys
try reproducing it with PARAVIRT off?
It won't help us that much if it won't trigger with PARAVIRT off
(the bug may just
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 wrote:
> > On Wed, 18 Mar 2015, Andy Lutomirski wrote:
> >
> >> sysret64 can only fail with #GP, and we're totally screwed if that
> >>
Good Morning :-)
Am 19.03.2015 um 01:57 schrieb Andy Lutomirski:
> Stefan, do you happen to know whether your disassembly of page_fault
> came from the instructions in memory or if they came from the vmlinux
> file? Not that I have any relevant ideas there.
I think they came from memory. At
Good Morning :-)
Am 19.03.2015 um 01:57 schrieb Andy Lutomirski:
Stefan, do you happen to know whether your disassembly of page_fault
came from the instructions in memory or if they came from the vmlinux
file? Not that I have any relevant ideas there.
I think they came from memory. At
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 jkos...@suse.cz wrote:
On Wed, 18 Mar 2015, Andy Lutomirski wrote:
sysret64 can only fail with #GP, and we're totally screwed if that
Having no more ideas at the moment, here is a tarball of 13 patches
of commits touching entry_64.S up to 4.0.0-rc1.
x0001.patch is the latest, x0015.patch is the oldest.
Patches 0003 and 0008 are not there since 0003 is empty merge patch
and 0008 does some PCI fixup.
If this breakage is recent,
On 03/19/2015 11:16 AM, Takashi Iwai wrote:
The kconfig is attached
You also have PARAVIRT enabled, like Stefan.
Just to obtain an additional data point, can you guys
try reproducing it with PARAVIRT off?
It won't help us that much if it won't trigger with PARAVIRT off
(the bug may just become
At Thu, 19 Mar 2015 11:58:19 +0100,
Denys Vlasenko wrote:
On 03/19/2015 11:16 AM, Takashi Iwai wrote:
The kconfig is attached
You also have PARAVIRT enabled, like Stefan.
Just to obtain an additional data point, can you guys
try reproducing it with PARAVIRT off?
It won't help us
At Thu, 19 Mar 2015 13:48:56 +0100,
Denys Vlasenko wrote:
Having no more ideas at the moment, here is a tarball of 13 patches
of commits touching entry_64.S up to 4.0.0-rc1.
x0001.patch is the latest, x0015.patch is the oldest.
Patches 0003 and 0008 are not there since 0003 is empty
On 03/18/2015 10:55 PM, Andy Lutomirski wrote:
On Wed, Mar 18, 2015 at 2:42 PM, Denys Vlasenko dvlas...@redhat.com wrote:
in 'irq_return_via_sysret' is new to 4.0, and instead of entering the
kernel with a user stack poiinter, maybe we're *exiting* the kernel,
and have just reloaded the user
At Thu, 19 Mar 2015 14:47:12 +0100,
Takashi Iwai wrote:
At Thu, 19 Mar 2015 13:48:56 +0100,
Denys Vlasenko wrote:
Having no more ideas at the moment, here is a tarball of 13 patches
of commits touching entry_64.S up to 4.0.0-rc1.
x0001.patch is the latest, x0015.patch is the
On Thu, Mar 19, 2015 at 8:51 AM, Takashi Iwai ti...@suse.de wrote:
At Thu, 19 Mar 2015 08:41:57 -0700,
Andy Lutomirski wrote:
On Thu, Mar 19, 2015 at 8:22 AM, Takashi Iwai ti...@suse.de wrote:
At Thu, 19 Mar 2015 15:55:26 +0100,
Takashi Iwai wrote:
At Thu, 19 Mar 2015 14:47:12 +0100,
At Thu, 19 Mar 2015 15:55:26 +0100,
Takashi Iwai wrote:
At Thu, 19 Mar 2015 14:47:12 +0100,
Takashi Iwai wrote:
At Thu, 19 Mar 2015 13:48:56 +0100,
Denys Vlasenko wrote:
Having no more ideas at the moment, here is a tarball of 13 patches
of commits touching entry_64.S up to
At Thu, 19 Mar 2015 08:41:57 -0700,
Andy Lutomirski wrote:
On Thu, Mar 19, 2015 at 8:22 AM, Takashi Iwai ti...@suse.de wrote:
At Thu, 19 Mar 2015 15:55:26 +0100,
Takashi Iwai wrote:
At Thu, 19 Mar 2015 14:47:12 +0100,
Takashi Iwai wrote:
At Thu, 19 Mar 2015 13:48:56 +0100,
On Thu, Mar 19, 2015 at 8:22 AM, Takashi Iwai ti...@suse.de wrote:
At Thu, 19 Mar 2015 15:55:26 +0100,
Takashi Iwai wrote:
At Thu, 19 Mar 2015 14:47:12 +0100,
Takashi Iwai wrote:
At Thu, 19 Mar 2015 13:48:56 +0100,
Denys Vlasenko wrote:
Having no more ideas at the moment, here is
On Wed, Mar 18, 2015 at 5:57 PM, Andy Lutomirski wrote:
>
>> sp = 140735967860552,
>
> 0x7fffa55f1748
>
> Note that the double fault happened with rsp == 0x7fffa55eafb8,
> which is the saved rsp here - 0x6790. That difference kind of large
> to make sense if this is a sysret problem. Not
On Wed, Mar 18, 2015 at 5:23 PM, Stefan Seyfried
wrote:
> Am 19.03.2015 um 00:22 schrieb Andy Lutomirski:
>> On Wed, Mar 18, 2015 at 3:40 PM, Andy Lutomirski wrote:
>>> Yes, it's userspace. Thanks for checking, though.
>>
>> One more stupid hunch:
>>
>> Can you do:
>> x/21xg 8801013d4f58
>>
Am 19.03.2015 um 00:22 schrieb Andy Lutomirski:
> On Wed, Mar 18, 2015 at 3:40 PM, Andy Lutomirski wrote:
>> Yes, it's userspace. Thanks for checking, though.
>
> One more stupid hunch:
>
> Can you do:
> x/21xg 8801013d4f58
>
> If I counted right, that'll dump task_pt_regs(current).
On Wed, Mar 18, 2015 at 3:40 PM, Andy Lutomirski wrote:
> On Wed, Mar 18, 2015 at 3:38 PM, Stefan Seyfried
> wrote:
>> Am 18.03.2015 um 23:29 schrieb Andy Lutomirski:
>>> On Wed, Mar 18, 2015 at 3:22 PM, Jiri Kosina wrote:
On Wed, 18 Mar 2015, Andy Lutomirski wrote:
> sysret64 can
On Wed, Mar 18, 2015 at 3:38 PM, Stefan Seyfried
wrote:
> Am 18.03.2015 um 23:29 schrieb Andy Lutomirski:
>> On Wed, Mar 18, 2015 at 3:22 PM, Jiri Kosina wrote:
>>> On Wed, 18 Mar 2015, Andy Lutomirski wrote:
>>>
sysret64 can only fail with #GP, and we're totally screwed if that
Am 18.03.2015 um 23:29 schrieb Andy Lutomirski:
> On Wed, Mar 18, 2015 at 3:22 PM, Jiri Kosina 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
On Wed, Mar 18, 2015 at 3:22 PM, Jiri Kosina 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.
On Wed, Mar 18, 2015 at 3:28 PM, Linus Torvalds
wrote:
> On Wed, Mar 18, 2015 at 3:22 PM, Jiri Kosina wrote:
>>
>> But what if the GPF handler pagefaults afterwards? It'd be operating on
>> user stack already.
>
> So I think this might be the answer. We don't see the GP fault,
> because we don't
On Wed, Mar 18, 2015 at 3:22 PM, Jiri Kosina wrote:
>
> But what if the GPF handler pagefaults afterwards? It'd be operating on
> user stack already.
So I think this might be the answer. We don't see the GP fault,
because we don't have a backtrace, because that backtrace is on the
user stack
On Wed, Mar 18, 2015 at 11:20 PM, Andy Lutomirski wrote:
>> There is an easy way to test the theory that SYSRET is to blame.
>>
>> Just replace
>>
>> movq RCX(%rsp),%rcx
>> cmpq %rcx,RIP(%rsp) /* RCX == RIP */
>> jne opportunistic_sysret_failed
>>
>> this "jne"
On Wed, Mar 18, 2015 at 3:18 PM, Linus Torvalds
wrote:
> On Wed, Mar 18, 2015 at 2:55 PM, Andy Lutomirski wrote:
>>
>> On Xen, it goes to xen_sysret64, which touches the same percpu
>> variables that we touch on entry. So I still like my percpu vmap
>> fault hypothesis, even though I don't
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.
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line
On Wed, Mar 18, 2015 at 3:17 PM, Denys Vlasenko wrote:
> On 03/18/2015 10:55 PM, Andy Lutomirski wrote:
>> On Wed, Mar 18, 2015 at 2:42 PM, Denys Vlasenko wrote:
>>> On 03/18/2015 10:32 PM, Linus Torvalds wrote:
On Wed, Mar 18, 2015 at 12:26 PM, Andy Lutomirski
wrote:
>>
>>
On Wed, Mar 18, 2015 at 2:55 PM, Andy Lutomirski wrote:
>
> On Xen, it goes to xen_sysret64, which touches the same percpu
> variables that we touch on entry. So I still like my percpu vmap
> fault hypothesis, even though I don't understand what would trigger
> it.
I don't dislike the theory
On 03/18/2015 10:55 PM, Andy Lutomirski wrote:
> On Wed, Mar 18, 2015 at 2:42 PM, Denys Vlasenko wrote:
>> On 03/18/2015 10:32 PM, Linus Torvalds wrote:
>>> On Wed, Mar 18, 2015 at 12:26 PM, Andy Lutomirski
>>> wrote:
>
> crash> disassemble page_fault
> Dump of assembler code for
On Wed, Mar 18, 2015 at 2:42 PM, Denys Vlasenko wrote:
> On 03/18/2015 10:32 PM, Linus Torvalds wrote:
>> On Wed, Mar 18, 2015 at 12:26 PM, Andy Lutomirski
>> wrote:
crash> disassemble page_fault
Dump of assembler code for function page_fault:
0x816834a0 <+0>:
Am 18.03.2015 um 22:49 schrieb Denys Vlasenko:
> Stefan, Takashi, can you post your /proc/cpuinfo
> and dmesg after boot?
susi:~ # cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Core(TM)2 Duo CPU L9400
Stefan, Takashi, can you post your /proc/cpuinfo
and dmesg after boot?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
Am 18.03.2015 um 22:32 schrieb Linus Torvalds:
> Is PARAVIRT enabled? The three nop's at the beginning of 'page_fault'
> makes me suspect it is, and that that is some paravirt rewriting
> area. What does paravirt go for that USERGS_SYSRET64 (or for
> SWAPGS_UNSAFE_STACK, for that matter).
This
On 03/18/2015 10:32 PM, Linus Torvalds wrote:
> On Wed, Mar 18, 2015 at 12:26 PM, Andy Lutomirski wrote:
>>>
>>> crash> disassemble page_fault
>>> Dump of assembler code for function page_fault:
>>>0x816834a0 <+0>: data32 xchg %ax,%ax
>>>0x816834a3 <+3>: data32
Am 18.03.2015 um 22:21 schrieb Andy Lutomirski:
> On Wed, Mar 18, 2015 at 2:12 PM, Stefan Seyfried
> wrote:
>> Am 18.03.2015 um 21:51 schrieb Andy Lutomirski:
>>> On Wed, Mar 18, 2015 at 1:05 PM, Stefan Seyfried
>>> wrote:
>>
> The relevant thread's stack is here (see ti in the trace):
>
On Wed, Mar 18, 2015 at 12:26 PM, Andy Lutomirski wrote:
>>
>> crash> disassemble page_fault
>> Dump of assembler code for function page_fault:
>>0x816834a0 <+0>: data32 xchg %ax,%ax
>>0x816834a3 <+3>: data32 xchg %ax,%ax
>>0x816834a6 <+6>: data32
On Wed, Mar 18, 2015 at 2:12 PM, Stefan Seyfried
wrote:
> Am 18.03.2015 um 21:51 schrieb Andy Lutomirski:
>> On Wed, Mar 18, 2015 at 1:05 PM, Stefan Seyfried
>> wrote:
>
The relevant thread's stack is here (see ti in the trace):
8801013d4000
It could be interesting
On Wed, Mar 18, 2015 at 2:06 PM, Denys Vlasenko wrote:
> On 03/18/2015 09:49 PM, Andy Lutomirski wrote:
>> On Wed, Mar 18, 2015 at 1:06 PM, Denys Vlasenko wrote:
>>> On 03/18/2015 08:26 PM, Andy Lutomirski wrote:
Hi Linus-
You seem to enjoy debugging these things. Want to give
Am 18.03.2015 um 21:51 schrieb Andy Lutomirski:
> On Wed, Mar 18, 2015 at 1:05 PM, Stefan Seyfried
> wrote:
>>> The relevant thread's stack is here (see ti in the trace):
>>>
>>> 8801013d4000
>>>
>>> It could be interesting to see what's there.
>>>
>>> I don't suppose you want to try to walk
On 03/18/2015 09:49 PM, Andy Lutomirski wrote:
> On Wed, Mar 18, 2015 at 1:06 PM, Denys Vlasenko wrote:
>> On 03/18/2015 08:26 PM, Andy Lutomirski wrote:
>>> Hi Linus-
>>>
>>> You seem to enjoy debugging these things. Want to give this a shot?
>>> My guess is a vmalloc fault accessing either
On Wed, Mar 18, 2015 at 1:05 PM, Stefan Seyfried
wrote:
> Hi Andy,
>
> Am 18.03.2015 um 20:26 schrieb Andy Lutomirski:
>> Hi Linus-
>>
>> You seem to enjoy debugging these things. Want to give this a shot?
>> My guess is a vmalloc fault accessing either old_rsp or kernel_stack
>> right after
On Wed, Mar 18, 2015 at 1:06 PM, Denys Vlasenko wrote:
> On 03/18/2015 08:26 PM, Andy Lutomirski wrote:
>> Hi Linus-
>>
>> You seem to enjoy debugging these things. Want to give this a shot?
>> My guess is a vmalloc fault accessing either old_rsp or kernel_stack
>> right after swapgs in syscall
On 03/18/2015 08:26 PM, Andy Lutomirski wrote:
> Hi Linus-
>
> You seem to enjoy debugging these things. Want to give this a shot?
> My guess is a vmalloc fault accessing either old_rsp or kernel_stack
> right after swapgs in syscall entry.
The code is:
ENTRY(system_call)
Hi Andy,
Am 18.03.2015 um 20:26 schrieb Andy Lutomirski:
> Hi Linus-
>
> You seem to enjoy debugging these things. Want to give this a shot?
> My guess is a vmalloc fault accessing either old_rsp or kernel_stack
> right after swapgs in syscall entry.
>
> On Wed, Mar 18, 2015 at 12:03 PM,
Hi Linus-
You seem to enjoy debugging these things. Want to give this a shot?
My guess is a vmalloc fault accessing either old_rsp or kernel_stack
right after swapgs in syscall entry.
On Wed, Mar 18, 2015 at 12:03 PM, Stefan Seyfried
wrote:
> Hi all,
>
> first, I'm kind of happy that I'm not
Hi all,
first, I'm kind of happy that I'm not the only one seeing this, and
thus my beloved Thinkpad can stay for a bit longer... :-)
Then, I'm mostly an amateur when it comes to kernel debugging, so bear
with me when I'm stumbling through the code...
Am 18.03.2015 um 19:03 schrieb Andy
On Wed, Mar 18, 2015 at 10:46 AM, Takashi Iwai wrote:
> At Wed, 18 Mar 2015 18:43:52 +0100,
> Takashi Iwai wrote:
>>
>> At Wed, 18 Mar 2015 15:16:42 +0100,
>> Takashi Iwai wrote:
>> >
>> > At Sun, 15 Mar 2015 09:17:15 +0100,
>> > Stefan Seyfried wrote:
>> > >
>> > > Hi all,
>> > >
>> > > in
At Wed, 18 Mar 2015 18:43:52 +0100,
Takashi Iwai wrote:
>
> At Wed, 18 Mar 2015 15:16:42 +0100,
> Takashi Iwai wrote:
> >
> > At Sun, 15 Mar 2015 09:17:15 +0100,
> > Stefan Seyfried wrote:
> > >
> > > Hi all,
> > >
> > > in 4.0-rc I have recently seen a few crashes, always when running
> > >
At Wed, 18 Mar 2015 15:16:42 +0100,
Takashi Iwai wrote:
>
> At Sun, 15 Mar 2015 09:17:15 +0100,
> Stefan Seyfried wrote:
> >
> > Hi all,
> >
> > in 4.0-rc I have recently seen a few crashes, always when running
> > KVM guests (IIRC). Today I was able to capture a crash dump, this
> > is the
At Wed, 18 Mar 2015 15:16:42 +0100,
Takashi Iwai wrote:
>
> IIRC, this didn't happen with the early 4.0-rc, but can't say 100%
> sure.
I could reproduce the panic on 4.0-rc1, so scratch this comment.
Takashi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
At Sun, 15 Mar 2015 09:17:15 +0100,
Stefan Seyfried wrote:
>
> Hi all,
>
> in 4.0-rc I have recently seen a few crashes, always when running
> KVM guests (IIRC). Today I was able to capture a crash dump, this
> is the backtrace from dmesg.txt:
>
> [242060.604870] PANIC: double fault,
At Wed, 18 Mar 2015 15:16:42 +0100,
Takashi Iwai wrote:
IIRC, this didn't happen with the early 4.0-rc, but can't say 100%
sure.
I could reproduce the panic on 4.0-rc1, so scratch this comment.
Takashi
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
At Sun, 15 Mar 2015 09:17:15 +0100,
Stefan Seyfried wrote:
Hi all,
in 4.0-rc I have recently seen a few crashes, always when running
KVM guests (IIRC). Today I was able to capture a crash dump, this
is the backtrace from dmesg.txt:
[242060.604870] PANIC: double fault, error_code: 0x0
At Wed, 18 Mar 2015 18:43:52 +0100,
Takashi Iwai wrote:
At Wed, 18 Mar 2015 15:16:42 +0100,
Takashi Iwai wrote:
At Sun, 15 Mar 2015 09:17:15 +0100,
Stefan Seyfried wrote:
Hi all,
in 4.0-rc I have recently seen a few crashes, always when running
KVM guests (IIRC). Today
At Wed, 18 Mar 2015 15:16:42 +0100,
Takashi Iwai wrote:
At Sun, 15 Mar 2015 09:17:15 +0100,
Stefan Seyfried wrote:
Hi all,
in 4.0-rc I have recently seen a few crashes, always when running
KVM guests (IIRC). Today I was able to capture a crash dump, this
is the backtrace from
On Wed, Mar 18, 2015 at 10:46 AM, Takashi Iwai ti...@suse.de wrote:
At Wed, 18 Mar 2015 18:43:52 +0100,
Takashi Iwai wrote:
At Wed, 18 Mar 2015 15:16:42 +0100,
Takashi Iwai wrote:
At Sun, 15 Mar 2015 09:17:15 +0100,
Stefan Seyfried wrote:
Hi all,
in 4.0-rc I have recently
1 - 100 of 134 matches
Mail list logo
