On Wed, Jan 27, 2010 at 8:07 AM, Ingo Molnar <mingo@xxxxxxx> wrote: > > * tip-bot for Brian Gerst <brgerst@xxxxxxxxx> wrote: > >> Commit-ID: f19a25c872b20ae4357f72687cf3e7b0da220ee2 >> Gitweb: http://git.kernel.org/tip/f19a25c872b20ae4357f72687cf3e7b0da220ee2 >> Author: Brian Gerst <brgerst@xxxxxxxxx> >> AuthorDate: Mon, 25 Jan 2010 10:47:33 -0500 >> Committer: H. Peter Anvin <hpa@xxxxxxxxx> >> CommitDate: Tue, 26 Jan 2010 23:38:14 -0800 >> >> x86-64: Use normal ptregs stub for execve >> >> Execve historically passed regs by value, so it had a seperate stub. >> This is no longer true, so change it to use a normal PTREGSCALL stub. >> >> Signed-off-by: Brian Gerst <brgerst@xxxxxxxxx> >> LKML-Reference: <1264434453-2204-1-git-send-email-brgerst@xxxxxxxxx> >> Signed-off-by: H. Peter Anvin <hpa@xxxxxxxxx> >> --- >> arch/x86/kernel/entry_64.S | 17 +---------------- >> 1 files changed, 1 insertions(+), 16 deletions(-) > > FYI, -tip testing found that this commit breaks the grub binary on 64-bit, > simply running /sbin/grub causes it to segfault: > > [ 3145.999766] grub[6706] general protection ip:805c481 sp:ff95629c error:0 in > grub[8048000+8c000] > > i've excluded this commit for now. > > Ingo > > I see what is going on. Grub is a 32-bit statically linked executable even on a 64-bit distro. The old execve stub forced return to userspace via iret, but PTREGSCALL apparently doesn't. This means that the 32-bit %cs isn't getting set. Drop this patch for now. -- Brian Gerst -- To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|