LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Jeff Dike <jdike@addtoit.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: user-mode-linux-devel@lists.sourceforge.net,
	linux-kernel@vger.kernel.org, tglx@linutronix.de, mingo@elte.hu
Subject: Re: uml doesn't work on 2.6.24-rc2
Date: Wed, 14 Nov 2007 12:36:39 -0500	[thread overview]
Message-ID: <20071114173639.GA7899@c2.user-mode-linux.org> (raw)
In-Reply-To: <E1IsK83-0008CJ-00@dorka.pomaz.szeredi.hu>

On Wed, Nov 14, 2007 at 04:26:11PM +0100, Miklos Szeredi wrote:
> This one fixed the EINVAL messages, and now UML boots, but consumes
> 100% CPU constantly.

Can you strace it and see if you are seeing zero-length nanosleeps,
and then send me your config file?  I've had one other report of this,
but haven't reproduced it here.

> > You'll also need f86f9e6d66027bdcdc9b40c06d431ee53ea0d509 for a
> > separate problem.
> 
> I can't find this in -linus.  Which tree is it?

My private tree, sorry - I looked at git-log output too quickly.  The
patch is below.  It's also in -mm.

> Never seen anything like this until 2.6.24.  Strange...

It breaks ptrace on 6-argument system calls made by 32-bit sysenter.

				Jeff

-- 
Work email - jdike at linux dot intel dot com

commit f86f9e6d66027bdcdc9b40c06d431ee53ea0d509
Author: Jeff Dike <jdike@addtoit.com>
Date:   Wed Nov 7 10:40:07 2007 -0500

    From: Chuck Ebbert <76306.1226@compuserve.com>
    
    [ jdike - Pushing Chuck's patch - see http://lkml.org/lkml/2005/9/16/261 ]
    
    When the 32-bit vDSO is used to make a system call, the %ebp register for
    the 6th syscall arg has to be loaded from the user stack (where it's pushed
    by the vDSO user code).  The native i386 kernel always does this before
    stopping for syscall tracing, so %ebp can be seen and modified via ptrace
    to access the 6th syscall argument.  The x86-64 kernel fails to do this,
    presenting the stack address to ptrace instead.  This makes the %rbp value
    seen by 64-bit ptrace of a 32-bit process, and the %ebp value seen by a
    32-bit caller of ptrace, both differ from the native i386 behavior.
    
    This patch fixes the problem by putting the word loaded from the user stack
    into %rbp before calling syscall_trace_enter, and reloading the 6th syscall
    argument from there afterwards (so ptrace can change it).  This makes the
    behavior match that of i386 kernels.
    
    Signed-off-by: Chuck Ebbert <76306.1226@compuserve.com>
    Signed-off-by: Jeff Dike <jdike@linux.intel.com>
    Original-Patch-By: Roland McGrath <roland@redhat.com>
    ---
     arch/x86_64/ia32/ia32entry.S |   19 ++++++-------------
     1 file changed, 6 insertions(+), 13 deletions(-)

diff --git a/arch/x86/ia32/ia32entry.S b/arch/x86/ia32/ia32entry.S
index 18b2318..df588f0 100644
--- a/arch/x86/ia32/ia32entry.S
+++ b/arch/x86/ia32/ia32entry.S
@@ -159,20 +159,16 @@ sysenter_do_call:
 
 sysenter_tracesys:
 	CFI_RESTORE_STATE
+	xchgl	%r9d,%ebp
 	SAVE_REST
 	CLEAR_RREGS
+	movq	%r9,R9(%rsp)
 	movq	$-ENOSYS,RAX(%rsp)	/* really needed? */
 	movq	%rsp,%rdi        /* &pt_regs -> arg1 */
 	call	syscall_trace_enter
 	LOAD_ARGS32 ARGOFFSET  /* reload args from stack in case ptrace changed it */
 	RESTORE_REST
-	movl	%ebp, %ebp
-	/* no need to do an access_ok check here because rbp has been
-	   32bit zero extended */ 
-1:	movl	(%rbp),%r9d
-	.section __ex_table,"a"
-	.quad 1b,ia32_badarg
-	.previous
+	xchgl	%ebp,%r9d
 	jmp	sysenter_do_call
 	CFI_ENDPROC
 ENDPROC(ia32_sysenter_target)
@@ -262,20 +258,17 @@ cstar_do_call:
 	
 cstar_tracesys:	
 	CFI_RESTORE_STATE
+	xchgl %r9d,%ebp
 	SAVE_REST
 	CLEAR_RREGS
+	movq %r9,R9(%rsp)
 	movq $-ENOSYS,RAX(%rsp)	/* really needed? */
 	movq %rsp,%rdi        /* &pt_regs -> arg1 */
 	call syscall_trace_enter
 	LOAD_ARGS32 ARGOFFSET  /* reload args from stack in case ptrace changed it */
 	RESTORE_REST
+	xchgl %ebp,%r9d
 	movl RSP-ARGOFFSET(%rsp), %r8d
-	/* no need to do an access_ok check here because r8 has been
-	   32bit zero extended */ 
-1:	movl	(%r8),%r9d
-	.section __ex_table,"a"
-	.quad 1b,ia32_badarg
-	.previous
 	jmp cstar_do_call
 END(ia32_cstar_target)
 				

  reply	other threads:[~2007-11-14 17:37 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-13 23:32 Miklos Szeredi
2007-11-14  1:10 ` Jeff Dike
2007-11-14 10:35   ` Miklos Szeredi
2007-11-14 14:22     ` Jeff Dike
2007-11-14 15:26       ` Miklos Szeredi
2007-11-14 17:36         ` Jeff Dike [this message]
2007-11-14 21:29           ` Miklos Szeredi
2007-11-16 17:06             ` Jeff Dike
2007-11-22 18:08               ` Miklos Szeredi
2007-11-22 23:51                 ` Jeff Dike
2007-11-23  8:59                   ` Miklos Szeredi
2007-11-23  9:01                   ` [uml-devel] " Karol Swietlicki
2007-11-23 10:54                     ` Jiri Olsa
2007-11-23 11:00                       ` WANG Cong
2007-11-26 17:47             ` Jeff Dike
2007-11-26 18:10             ` Jeff Dike
2007-11-26 20:52         ` Jeff Dike
2007-11-26 21:22           ` Miklos Szeredi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20071114173639.GA7899@c2.user-mode-linux.org \
    --to=jdike@addtoit.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=mingo@elte.hu \
    --cc=tglx@linutronix.de \
    --cc=user-mode-linux-devel@lists.sourceforge.net \
    --subject='Re: uml doesn'\''t work on 2.6.24-rc2' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).