* 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