Also PTRACE_OLDSETOPTIONS should be accepted, as done by kernel/ptrace.c and
forced by binary compatibility. UML/32bit breaks because of this - since it is wise
enough to use PTRACE_OLDSETOPTIONS to be binary compatible with 2.4 host
kernels.
Until 2.6.17 (commit f0f2d6536e3515b5b1b7ae97dc8f176860c8c2ce) we had:
default:
return sys_ptrace(request, pid, addr, data);
Instead here we have:
case PTRACE_GET_THREAD_AREA:
case ...:
return sys_ptrace(request, pid, addr, data);
default:
return -EINVAL;
This change was a style change - when a case is added, it must be explicitly
tested this way. In this case, not enough testing was done.
Cc: Andi Kleen <[email protected]>
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[email protected]>
Index: linux-2.6.git/arch/x86_64/ia32/ptrace32.c
===================================================================
--- linux-2.6.git.orig/arch/x86_64/ia32/ptrace32.c
+++ linux-2.6.git/arch/x86_64/ia32/ptrace32.c
@@ -246,6 +246,7 @@ asmlinkage long sys32_ptrace(long reques
case PTRACE_SINGLESTEP:
case PTRACE_DETACH:
case PTRACE_SYSCALL:
+ case PTRACE_OLDSETOPTIONS:
case PTRACE_SETOPTIONS:
case PTRACE_SET_THREAD_AREA:
case PTRACE_GET_THREAD_AREA:
On Thu, Feb 15, 2007 at 03:34:23AM +0100, Paolo 'Blaisorblade' Giarrusso wrote:
> Index: linux-2.6.git/arch/x86_64/ia32/ptrace32.c
> ===================================================================
> --- linux-2.6.git.orig/arch/x86_64/ia32/ptrace32.c
> +++ linux-2.6.git/arch/x86_64/ia32/ptrace32.c
> @@ -246,6 +246,7 @@ asmlinkage long sys32_ptrace(long reques
> case PTRACE_SINGLESTEP:
> case PTRACE_DETACH:
> case PTRACE_SYSCALL:
> + case PTRACE_OLDSETOPTIONS:
> case PTRACE_SETOPTIONS:
> case PTRACE_SET_THREAD_AREA:
> case PTRACE_GET_THREAD_AREA:
>
I sent an equivalent patch in earlier today:
Index: linux-2.6/arch/x86_64/ia32/ptrace32.c
===================================================================
--- linux-2.6.orig/arch/x86_64/ia32/ptrace32.c
+++ linux-2.6/arch/x86_64/ia32/ptrace32.c
@@ -239,6 +239,8 @@ asmlinkage long sys32_ptrace(long reques
__u32 val;
switch (request) {
+ case PTRACE_OLDSETOPTIONS:
+ request = PTRACE_SETOPTIONS;
case PTRACE_TRACEME:
case PTRACE_ATTACH:
case PTRACE_KILL:
I change the request so that PTRACE_OLDSETOPTIONS doesn't need to
propogate any further. However, it is present in include/asm-x86_64,
so I guess that counts as being part of the x86_64 ABI. That being
the case, I guess my patch can be dropped in favor of this one.
Jeff
--
Work email - jdike at linux dot intel dot com
On Thursday 15 February 2007 03:54, Jeff Dike wrote:
> On Thu, Feb 15, 2007 at 03:34:23AM +0100, Paolo 'Blaisorblade' Giarrusso
wrote:
> > Index: linux-2.6.git/arch/x86_64/ia32/ptrace32.c
> > ===================================================================
> > --- linux-2.6.git.orig/arch/x86_64/ia32/ptrace32.c
> > +++ linux-2.6.git/arch/x86_64/ia32/ptrace32.c
> > @@ -246,6 +246,7 @@ asmlinkage long sys32_ptrace(long reques
> > case PTRACE_SINGLESTEP:
> > case PTRACE_DETACH:
> > case PTRACE_SYSCALL:
> > + case PTRACE_OLDSETOPTIONS:
> > case PTRACE_SETOPTIONS:
> > case PTRACE_SET_THREAD_AREA:
> > case PTRACE_GET_THREAD_AREA:
>
> I sent an equivalent patch in earlier today:
Doh! Interesting this timing...
> Index: linux-2.6/arch/x86_64/ia32/ptrace32.c
> ===================================================================
> --- linux-2.6.orig/arch/x86_64/ia32/ptrace32.c
> +++ linux-2.6/arch/x86_64/ia32/ptrace32.c
> @@ -239,6 +239,8 @@ asmlinkage long sys32_ptrace(long reques
> __u32 val;
>
> switch (request) {
> + case PTRACE_OLDSETOPTIONS:
> + request = PTRACE_SETOPTIONS;
> case PTRACE_TRACEME:
> case PTRACE_ATTACH:
> case PTRACE_KILL:
>
> I change the request so that PTRACE_OLDSETOPTIONS doesn't need to
> propogate any further. However, it is present in include/asm-x86_64,
> so I guess that counts as being part of the x86_64 ABI. That being
> the case, I guess my patch can be dropped in favor of this one.
It is handled in ptrace_request, unless there are include problems. I'm going
to reboot and test mine for any remaining problem.
--
Inform me of my mistakes, so I can add them to my list!
Paolo Giarrusso, aka Blaisorblade
http://www.user-mode-linux.org/~blaisorblade
Chiacchiera con i tuoi amici in tempo reale!
http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com
On Thu, 15 Feb 2007 04:43:41 +0100 Blaisorblade <[email protected]> wrote:
> > I sent an equivalent patch in earlier today:
> Doh! Interesting this timing...
>
> > Index: linux-2.6/arch/x86_64/ia32/ptrace32.c
> > ===================================================================
> > --- linux-2.6.orig/arch/x86_64/ia32/ptrace32.c
> > +++ linux-2.6/arch/x86_64/ia32/ptrace32.c
> > @@ -239,6 +239,8 @@ asmlinkage long sys32_ptrace(long reques
> > __u32 val;
> >
> > switch (request) {
> > + case PTRACE_OLDSETOPTIONS:
> > + request = PTRACE_SETOPTIONS;
> > case PTRACE_TRACEME:
> > case PTRACE_ATTACH:
> > case PTRACE_KILL:
> >
> > I change the request so that PTRACE_OLDSETOPTIONS doesn't need to
> > propogate any further. However, it is present in include/asm-x86_64,
> > so I guess that counts as being part of the x86_64 ABI. That being
> > the case, I guess my patch can be dropped in favor of this one.
>
> It is handled in ptrace_request, unless there are include problems. I'm going
> to reboot and test mine for any remaining problem.
Whatever happens, please ensure that the final fix makes it into -stable
as well. Jeff's version of this patch wasn't cc'ed to [email protected].
On Wed, Feb 14, 2007 at 09:51:23PM -0800, Andrew Morton wrote:
> Whatever happens, please ensure that the final fix makes it into -stable
> as well. Jeff's version of this patch wasn't cc'ed to [email protected].
Paolo's patch was sent to -stable. His should be used everywhere, and mine
should be dropped.
Jeff
--
Work email - jdike at linux dot intel dot com
On Thursday 15 February 2007 18:01, Jeff Dike wrote:
> On Wed, Feb 14, 2007 at 09:51:23PM -0800, Andrew Morton wrote:
> > Whatever happens, please ensure that the final fix makes it into -stable
> > as well. Jeff's version of this patch wasn't cc'ed to [email protected].
>
> Paolo's patch was sent to -stable. His should be used everywhere, and mine
> should be dropped.
Jeff, I verified my patch is _almost_ enough for 2.6.18 for fully booting a
32bit UML; on 2.6.18 I had to also add PTRACE_GET/SET_THREAD_AREA (this fix
was merged in 2.6.19) to avoid tons of TLS errors.
On 2.6.19, the crash at boot is removed (btw, that crash output no message - I
hope that with your fatal/nonfatal/etc. introduction I would get a message)
but another one happens when starting init. I'll test 2.6.20 ASAP.
Bye
--
Inform me of my mistakes, so I can add them to my list!
Paolo Giarrusso, aka Blaisorblade
http://www.user-mode-linux.org/~blaisorblade
Chiacchiera con i tuoi amici in tempo reale!
http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com
On Thu, Feb 15, 2007 at 08:05:56PM +0100, Blaisorblade wrote:
> Jeff, I verified my patch is _almost_ enough for 2.6.18 for fully booting a
> 32bit UML; on 2.6.18 I had to also add PTRACE_GET/SET_THREAD_AREA (this fix
> was merged in 2.6.19) to avoid tons of TLS errors.
I'm not seeing that. With the current set of patches, I have 32-bit UMLs
happily booting on x86_64.
Jeff
--
Work email - jdike at linux dot intel dot com
On Friday 16 February 2007 20:02, Jeff Dike wrote:
> On Thu, Feb 15, 2007 at 08:05:56PM +0100, Blaisorblade wrote:
> > Jeff, I verified my patch is _almost_ enough for 2.6.18 for fully booting
> > a 32bit UML; on 2.6.18 I had to also add PTRACE_GET/SET_THREAD_AREA (this
> > fix was merged in 2.6.19) to avoid tons of TLS errors.
>
> I'm not seeing that. With the current set of patches, I have 32-bit UMLs
> happily booting on x86_64.
Which kernel? I've not yet tested 2.6.20. I'll try debugging this
subsequently.
--
Inform me of my mistakes, so I can add them to my list!
Paolo Giarrusso, aka Blaisorblade
http://www.user-mode-linux.org/~blaisorblade
Chiacchiera con i tuoi amici in tempo reale!
http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com
On Sat, Feb 17, 2007 at 01:04:35AM +0100, Blaisorblade wrote:
> Which kernel? I've not yet tested 2.6.20. I'll try debugging this
> subsequently.
2.6.20-rc6-mm3 on 2.6.20 + patches works for me.
Jeff
--
Work email - jdike at linux dot intel dot com