* Issues with "x86, um: switch to generic fork/vfork/clone" commit
@ 2012-11-10 4:36 Michel Lespinasse
2012-11-10 4:51 ` Al Viro
0 siblings, 1 reply; 8+ messages in thread
From: Michel Lespinasse @ 2012-11-10 4:36 UTC (permalink / raw)
To: Al Viro, linux-next; +Cc: LKML, Hugh Dickins
Hi,
I'm having an issue booting current linux-next kernels on my test
machines. Userspace crashes when it's supposed to pivot to the rootfs.
With the loglevel=8 kernel parameter, the last messages I see are:
Checking root filesystem in pivot_root init.
[ 6.252717] usb 2-1: link qh256-0001/ffff880853ec9ab8 start 1 [1/0 us]
[ 6.259419] hub 2-1:1.0: state 7 ports 8 chg 0000 evt 0000
[ 6.292302] traps: hotplug[1633] general protection ip:f767c06b
sp:ffbb2d1c error:0 in libc-2.3.6.so[f7652000+126000]
I ran a bisection and it turns out that
e52d03a3775841cc68d0ea9d86f2f09b603c41e6 (x86, um: switch to generic
fork/vfork/clone) is the commit breaking my setup. When reverting
that, I am able to boot linux-next (or mmotm, which is what I was
trying to do in the first place) without issues.
Sorry for not having a more complete root cause at the moment - I'm
lacking some context as to what the change is trying to do.
--
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Issues with "x86, um: switch to generic fork/vfork/clone" commit
2012-11-10 4:36 Issues with "x86, um: switch to generic fork/vfork/clone" commit Michel Lespinasse
@ 2012-11-10 4:51 ` Al Viro
2012-11-10 4:57 ` Michel Lespinasse
0 siblings, 1 reply; 8+ messages in thread
From: Al Viro @ 2012-11-10 4:51 UTC (permalink / raw)
To: Michel Lespinasse; +Cc: linux-next, LKML, Hugh Dickins
On Fri, Nov 09, 2012 at 08:36:53PM -0800, Michel Lespinasse wrote:
> Hi,
>
> I'm having an issue booting current linux-next kernels on my test
> machines. Userspace crashes when it's supposed to pivot to the rootfs.
> With the loglevel=8 kernel parameter, the last messages I see are:
>
> Checking root filesystem in pivot_root init.
> [ 6.252717] usb 2-1: link qh256-0001/ffff880853ec9ab8 start 1 [1/0 us]
> [ 6.259419] hub 2-1:1.0: state 7 ports 8 chg 0000 evt 0000
> [ 6.292302] traps: hotplug[1633] general protection ip:f767c06b
> sp:ffbb2d1c error:0 in libc-2.3.6.so[f7652000+126000]
>
> I ran a bisection and it turns out that
> e52d03a3775841cc68d0ea9d86f2f09b603c41e6 (x86, um: switch to generic
> fork/vfork/clone) is the commit breaking my setup. When reverting
> that, I am able to boot linux-next (or mmotm, which is what I was
> trying to do in the first place) without issues.
>
> Sorry for not having a more complete root cause at the moment - I'm
> lacking some context as to what the change is trying to do.
Hmm... 32bit native, presumably?
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Issues with "x86, um: switch to generic fork/vfork/clone" commit
2012-11-10 4:51 ` Al Viro
@ 2012-11-10 4:57 ` Michel Lespinasse
2012-11-10 5:33 ` Al Viro
0 siblings, 1 reply; 8+ messages in thread
From: Michel Lespinasse @ 2012-11-10 4:57 UTC (permalink / raw)
To: Al Viro; +Cc: linux-next, LKML, Hugh Dickins
On Fri, Nov 9, 2012 at 8:51 PM, Al Viro <viro@zeniv•linux.org.uk> wrote:
> On Fri, Nov 09, 2012 at 08:36:53PM -0800, Michel Lespinasse wrote:
>> Hi,
>>
>> I'm having an issue booting current linux-next kernels on my test
>> machines. Userspace crashes when it's supposed to pivot to the rootfs.
>> With the loglevel=8 kernel parameter, the last messages I see are:
>>
>> Checking root filesystem in pivot_root init.
>> [ 6.252717] usb 2-1: link qh256-0001/ffff880853ec9ab8 start 1 [1/0 us]
>> [ 6.259419] hub 2-1:1.0: state 7 ports 8 chg 0000 evt 0000
>> [ 6.292302] traps: hotplug[1633] general protection ip:f767c06b
>> sp:ffbb2d1c error:0 in libc-2.3.6.so[f7652000+126000]
>>
>> I ran a bisection and it turns out that
>> e52d03a3775841cc68d0ea9d86f2f09b603c41e6 (x86, um: switch to generic
>> fork/vfork/clone) is the commit breaking my setup. When reverting
>> that, I am able to boot linux-next (or mmotm, which is what I was
>> trying to do in the first place) without issues.
>>
>> Sorry for not having a more complete root cause at the moment - I'm
>> lacking some context as to what the change is trying to do.
>
> Hmm... 32bit native, presumably?
This is running on a x86_64 system; I believe the userspace binaries
should be 64-bit as well.
--
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Issues with "x86, um: switch to generic fork/vfork/clone" commit
2012-11-10 4:57 ` Michel Lespinasse
@ 2012-11-10 5:33 ` Al Viro
2012-11-10 5:47 ` Michel Lespinasse
0 siblings, 1 reply; 8+ messages in thread
From: Al Viro @ 2012-11-10 5:33 UTC (permalink / raw)
To: Michel Lespinasse; +Cc: linux-next, LKML, Hugh Dickins
On Fri, Nov 09, 2012 at 08:57:58PM -0800, Michel Lespinasse wrote:
> On Fri, Nov 9, 2012 at 8:51 PM, Al Viro <viro@zeniv•linux.org.uk> wrote:
> > On Fri, Nov 09, 2012 at 08:36:53PM -0800, Michel Lespinasse wrote:
> >> Hi,
> >>
> >> I'm having an issue booting current linux-next kernels on my test
> >> machines. Userspace crashes when it's supposed to pivot to the rootfs.
> >> With the loglevel=8 kernel parameter, the last messages I see are:
> >>
> >> Checking root filesystem in pivot_root init.
> >> [ 6.252717] usb 2-1: link qh256-0001/ffff880853ec9ab8 start 1 [1/0 us]
> >> [ 6.259419] hub 2-1:1.0: state 7 ports 8 chg 0000 evt 0000
> >> [ 6.292302] traps: hotplug[1633] general protection ip:f767c06b
> >> sp:ffbb2d1c error:0 in libc-2.3.6.so[f7652000+126000]
> >>
> >> I ran a bisection and it turns out that
> >> e52d03a3775841cc68d0ea9d86f2f09b603c41e6 (x86, um: switch to generic
> >> fork/vfork/clone) is the commit breaking my setup. When reverting
> >> that, I am able to boot linux-next (or mmotm, which is what I was
> >> trying to do in the first place) without issues.
> >>
> >> Sorry for not having a more complete root cause at the moment - I'm
> >> lacking some context as to what the change is trying to do.
> >
> > Hmm... 32bit native, presumably?
>
> This is running on a x86_64 system; I believe the userspace binaries
> should be 64-bit as well.
Curious... After the second look at that sucker, it seems that you have
32bit hotplug(8) in there, and yes, it's clearly a 64bit kernel... Could
you check which binary it is and whether it's really 32bit or not?
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Issues with "x86, um: switch to generic fork/vfork/clone" commit
2012-11-10 5:33 ` Al Viro
@ 2012-11-10 5:47 ` Michel Lespinasse
2012-11-10 7:33 ` Al Viro
0 siblings, 1 reply; 8+ messages in thread
From: Michel Lespinasse @ 2012-11-10 5:47 UTC (permalink / raw)
To: Al Viro; +Cc: linux-next, LKML, Hugh Dickins
On Fri, Nov 9, 2012 at 9:33 PM, Al Viro <viro@zeniv•linux.org.uk> wrote:
> On Fri, Nov 09, 2012 at 08:57:58PM -0800, Michel Lespinasse wrote:
>> On Fri, Nov 9, 2012 at 8:51 PM, Al Viro <viro@zeniv•linux.org.uk> wrote:
>> > On Fri, Nov 09, 2012 at 08:36:53PM -0800, Michel Lespinasse wrote:
>> >> Hi,
>> >>
>> >> I'm having an issue booting current linux-next kernels on my test
>> >> machines. Userspace crashes when it's supposed to pivot to the rootfs.
>> >> With the loglevel=8 kernel parameter, the last messages I see are:
>> >>
>> >> Checking root filesystem in pivot_root init.
>> >> [ 6.252717] usb 2-1: link qh256-0001/ffff880853ec9ab8 start 1 [1/0 us]
>> >> [ 6.259419] hub 2-1:1.0: state 7 ports 8 chg 0000 evt 0000
>> >> [ 6.292302] traps: hotplug[1633] general protection ip:f767c06b
>> >> sp:ffbb2d1c error:0 in libc-2.3.6.so[f7652000+126000]
>> >>
>> >> I ran a bisection and it turns out that
>> >> e52d03a3775841cc68d0ea9d86f2f09b603c41e6 (x86, um: switch to generic
>> >> fork/vfork/clone) is the commit breaking my setup. When reverting
>> >> that, I am able to boot linux-next (or mmotm, which is what I was
>> >> trying to do in the first place) without issues.
>> >>
>> >> Sorry for not having a more complete root cause at the moment - I'm
>> >> lacking some context as to what the change is trying to do.
>> >
>> > Hmm... 32bit native, presumably?
>>
>> This is running on a x86_64 system; I believe the userspace binaries
>> should be 64-bit as well.
>
> Curious... After the second look at that sucker, it seems that you have
> 32bit hotplug(8) in there, and yes, it's clearly a 64bit kernel... Could
> you check which binary it is and whether it's really 32bit or not?
Looks like /sbin/hotplug is a script on this system, using /bin/bash
as the interpreter, and /bin/bash is ELF 32-bit LSB executable.
(wow, I had no idea, I thought more of that system was 64-bits :)
--
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Issues with "x86, um: switch to generic fork/vfork/clone" commit
2012-11-10 5:47 ` Michel Lespinasse
@ 2012-11-10 7:33 ` Al Viro
2012-11-10 8:08 ` Michel Lespinasse
2012-11-10 18:59 ` Al Viro
0 siblings, 2 replies; 8+ messages in thread
From: Al Viro @ 2012-11-10 7:33 UTC (permalink / raw)
To: Michel Lespinasse; +Cc: linux-next, LKML, Hugh Dickins
On Fri, Nov 09, 2012 at 09:47:54PM -0800, Michel Lespinasse wrote:
> On Fri, Nov 9, 2012 at 9:33 PM, Al Viro <viro@zeniv•linux.org.uk> wrote:
> > On Fri, Nov 09, 2012 at 08:57:58PM -0800, Michel Lespinasse wrote:
> >> On Fri, Nov 9, 2012 at 8:51 PM, Al Viro <viro@zeniv•linux.org.uk> wrote:
> >> > On Fri, Nov 09, 2012 at 08:36:53PM -0800, Michel Lespinasse wrote:
> >> >> Hi,
> >> >>
> >> >> I'm having an issue booting current linux-next kernels on my test
> >> >> machines. Userspace crashes when it's supposed to pivot to the rootfs.
> >> >> With the loglevel=8 kernel parameter, the last messages I see are:
> >> >>
> >> >> Checking root filesystem in pivot_root init.
> >> >> [ 6.252717] usb 2-1: link qh256-0001/ffff880853ec9ab8 start 1 [1/0 us]
> >> >> [ 6.259419] hub 2-1:1.0: state 7 ports 8 chg 0000 evt 0000
> >> >> [ 6.292302] traps: hotplug[1633] general protection ip:f767c06b
> >> >> sp:ffbb2d1c error:0 in libc-2.3.6.so[f7652000+126000]
> >> >>
> >> >> I ran a bisection and it turns out that
> >> >> e52d03a3775841cc68d0ea9d86f2f09b603c41e6 (x86, um: switch to generic
> >> >> fork/vfork/clone) is the commit breaking my setup. When reverting
> >> >> that, I am able to boot linux-next (or mmotm, which is what I was
> >> >> trying to do in the first place) without issues.
> >> >>
> >> >> Sorry for not having a more complete root cause at the moment - I'm
> >> >> lacking some context as to what the change is trying to do.
> >> >
> >> > Hmm... 32bit native, presumably?
> >>
> >> This is running on a x86_64 system; I believe the userspace binaries
> >> should be 64-bit as well.
> >
> > Curious... After the second look at that sucker, it seems that you have
> > 32bit hotplug(8) in there, and yes, it's clearly a 64bit kernel... Could
> > you check which binary it is and whether it's really 32bit or not?
>
> Looks like /sbin/hotplug is a script on this system, using /bin/bash
> as the interpreter, and /bin/bash is ELF 32-bit LSB executable.
> (wow, I had no idea, I thought more of that system was 64-bits :)
I think I see what's going on there. It's PTREGSCALL blindly used for
clone wrapper in ia32entry.S. FWIW, it's wrong for all of those
suckers, anyway:
* fork/clone/vfork need to save extra registers, but don't need
to restore them; after unification we don't need pt_regs argument for any
of those - for fork/vfork it's useless, for clone it breaks things.
* execve doesn't need pt_regs argument; harmless, but useless.
* for sigaltstack() we simply need to get rid of stupid pt_regs
argument, along with the wrapper; current_pt_regs()->sp is all it needs.
* for sigreturn/rt_sigreturn we need to restore extra registers,
but we do *not* need to save them; just leave the space on stack. And
no need to pass pt_regs either - it'll be current_pt_regs() anyway.
* iopl() doesn't need to save/restore extras and it doesn't need
pt_regs argument - it's going to be current_pt_regs().
On top of all that, there's an extra piece of crap - different order of
arguments for native and compat clone.
Could you verify that this on top of for-next gets the things working again?
It's a very lazy way to deal with that (we don't want to bother with
restoring extras, at the very least), but the rest can go separately (and
is shared with mainline, unlike that one). It seems to be working here,
but I'd like to see your ACK as well. If everything works, it'll get
folded into the offending commit...
diff --git a/arch/x86/ia32/ia32entry.S b/arch/x86/ia32/ia32entry.S
index 633649e..32e6f05 100644
--- a/arch/x86/ia32/ia32entry.S
+++ b/arch/x86/ia32/ia32entry.S
@@ -467,11 +467,16 @@ GLOBAL(\label)
PTREGSCALL stub32_sigaltstack, sys32_sigaltstack, %rdx
PTREGSCALL stub32_execve, compat_sys_execve, %rcx
PTREGSCALL stub32_fork, sys_fork, %rdi
- PTREGSCALL stub32_clone, sys_clone, %rdx
PTREGSCALL stub32_vfork, sys_vfork, %rdi
PTREGSCALL stub32_iopl, sys_iopl, %rsi
ALIGN
+GLOBAL(stub32_clone)
+ leaq sys_clone(%rip),%rax
+ mov %r8, %rcx
+ jmp ia32_ptregs_common
+
+ ALIGN
ia32_ptregs_common:
popq %r11
CFI_ENDPROC
Anyway, below is the minimal fix on top of for-next; I'll fold it
^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: Issues with "x86, um: switch to generic fork/vfork/clone" commit
2012-11-10 7:33 ` Al Viro
@ 2012-11-10 8:08 ` Michel Lespinasse
2012-11-10 18:59 ` Al Viro
1 sibling, 0 replies; 8+ messages in thread
From: Michel Lespinasse @ 2012-11-10 8:08 UTC (permalink / raw)
To: Al Viro; +Cc: linux-next, LKML, Hugh Dickins
On Fri, Nov 9, 2012 at 11:33 PM, Al Viro <viro@zeniv•linux.org.uk> wrote:
> Could you verify that this on top of for-next gets the things working again?
> It's a very lazy way to deal with that (we don't want to bother with
> restoring extras, at the very least), but the rest can go separately (and
> is shared with mainline, unlike that one). It seems to be working here,
> but I'd like to see your ACK as well. If everything works, it'll get
> folded into the offending commit...
>
> diff --git a/arch/x86/ia32/ia32entry.S b/arch/x86/ia32/ia32entry.S
> index 633649e..32e6f05 100644
> --- a/arch/x86/ia32/ia32entry.S
> +++ b/arch/x86/ia32/ia32entry.S
> @@ -467,11 +467,16 @@ GLOBAL(\label)
> PTREGSCALL stub32_sigaltstack, sys32_sigaltstack, %rdx
> PTREGSCALL stub32_execve, compat_sys_execve, %rcx
> PTREGSCALL stub32_fork, sys_fork, %rdi
> - PTREGSCALL stub32_clone, sys_clone, %rdx
> PTREGSCALL stub32_vfork, sys_vfork, %rdi
> PTREGSCALL stub32_iopl, sys_iopl, %rsi
>
> ALIGN
> +GLOBAL(stub32_clone)
> + leaq sys_clone(%rip),%rax
> + mov %r8, %rcx
> + jmp ia32_ptregs_common
> +
> + ALIGN
> ia32_ptregs_common:
> popq %r11
> CFI_ENDPROC
Yes, I tested the above by applying it on top of mmotm and it did
solve the issue.
Thanks,
--
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Issues with "x86, um: switch to generic fork/vfork/clone" commit
2012-11-10 7:33 ` Al Viro
2012-11-10 8:08 ` Michel Lespinasse
@ 2012-11-10 18:59 ` Al Viro
1 sibling, 0 replies; 8+ messages in thread
From: Al Viro @ 2012-11-10 18:59 UTC (permalink / raw)
To: Michel Lespinasse; +Cc: linux-next, LKML, Hugh Dickins
On Sat, Nov 10, 2012 at 07:33:39AM +0000, Al Viro wrote:
> I think I see what's going on there. It's PTREGSCALL blindly used for
> clone wrapper in ia32entry.S. FWIW, it's wrong for all of those
> suckers, anyway:
> * fork/clone/vfork need to save extra registers, but don't need
> to restore them; after unification we don't need pt_regs argument for any
> of those - for fork/vfork it's useless, for clone it breaks things.
> * execve doesn't need pt_regs argument; harmless, but useless.
> * for sigaltstack() we simply need to get rid of stupid pt_regs
> argument, along with the wrapper; current_pt_regs()->sp is all it needs.
> * for sigreturn/rt_sigreturn we need to restore extra registers,
> but we do *not* need to save them; just leave the space on stack. And
> no need to pass pt_regs either - it'll be current_pt_regs() anyway.
> * iopl() doesn't need to save/restore extras and it doesn't need
> pt_regs argument - it's going to be current_pt_regs().
Alas, sigaltack() and iopl() do need a bit of a wrapper; they don't care
about extras, but they wants ->sp and ->flags resp., which means needing
to go through FIXUP_TOP_OF_STACK on amd64 ;-/
> On top of all that, there's an extra piece of crap - different order of
> arguments for native and compat clone.
... and the same commit slightly buggers clone(2) on amd64 as well. Grr...
Anyway, fixed and pushed; please, test for-next when it propagates, head
should be at fae45353de587ae6a949dbf21ee06d5dd652248c
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2012-11-10 18:59 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-11-10 4:36 Issues with "x86, um: switch to generic fork/vfork/clone" commit Michel Lespinasse
2012-11-10 4:51 ` Al Viro
2012-11-10 4:57 ` Michel Lespinasse
2012-11-10 5:33 ` Al Viro
2012-11-10 5:47 ` Michel Lespinasse
2012-11-10 7:33 ` Al Viro
2012-11-10 8:08 ` Michel Lespinasse
2012-11-10 18:59 ` Al Viro
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox