From: Jeff D. <jd...@ad...> - 2007-03-23 19:41:23
|
This fixes a problem seen by a number of people running UML on newer host kernels. init would hang with an infinite segfault loop. It turns out that the host kernel was providing a AT_SYSINFO_EHDR of 0xffffe000, which faked UML into believing that the host VDSO page could be reused. However, AT_SYSINFO pointed into the middle of the address space, and was unmapped as a result. Because UML was providing AT_SYSINFO_EHDR and AT_SYSINFO to its own processes, these would branch to nowhere when trying to use the VDSO. The fix is to also check the location of AT_SYSINFO when deciding whether to use the host's VDSO. Signed-off-by: Jeff Dike <jd...@li...> -- arch/um/os-Linux/elf_aux.c | 3 +++ 1 file changed, 3 insertions(+) Index: linux-2.6.17/arch/um/os-Linux/elf_aux.c =================================================================== --- linux-2.6.17.orig/arch/um/os-Linux/elf_aux.c 2007-02-23 15:00:51.000000000 -0500 +++ linux-2.6.17/arch/um/os-Linux/elf_aux.c 2007-02-23 15:09:58.000000000 -0500 @@ -39,6 +39,9 @@ __init void scan_elf_aux( char **envp) switch ( auxv->a_type ) { case AT_SYSINFO: __kernel_vsyscall = auxv->a_un.a_val; + /* See if the page is under TASK_SIZE */ + if (__kernel_vsyscall < (unsigned long) envp) + __kernel_vsyscall = 0; break; case AT_SYSINFO_EHDR: vsyscall_ehdr = auxv->a_un.a_val; |
From: Brock, A. - N. <Ant...@or...> - 2007-03-23 21:05:48
|
Jeff, Is this going into stable or devel? If stable, what version? Also, do you know what version of the host kernels introduced this behavior? Sorry for all the questions, but I believe this is the bug I've been waiting on for a while (affecting host kernels greater than 2.6.17, or something of that nature). Thanks! Tony > -----Original Message----- > From: use...@li...=20 > [mailto:use...@li...]=20 > On Behalf Of Jeff Dike > Sent: Friday, March 23, 2007 12:38 PM > To: st...@ke... > Cc: LKML; uml-devel > Subject: [uml-devel] [PATCH] UML - host VDSO fix >=20 > This fixes a problem seen by a number of people running UML=20 > on newer host > kernels. init would hang with an infinite segfault loop. >=20 > It turns out that the host kernel was providing a AT_SYSINFO_EHDR of > 0xffffe000, which faked UML into believing that the host VDSO=20 > page could be > reused. However, AT_SYSINFO pointed into the middle of the=20 > address space, and > was unmapped as a result. Because UML was providing=20 > AT_SYSINFO_EHDR and > AT_SYSINFO to its own processes, these would branch to=20 > nowhere when trying to > use the VDSO. >=20 > The fix is to also check the location of AT_SYSINFO when=20 > deciding whether to > use the host's VDSO. >=20 > Signed-off-by: Jeff Dike <jd...@li...> > -- > arch/um/os-Linux/elf_aux.c | 3 +++ > 1 file changed, 3 insertions(+) >=20 > Index: linux-2.6.17/arch/um/os-Linux/elf_aux.c > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- linux-2.6.17.orig/arch/um/os-Linux/elf_aux.c=09 > 2007-02-23 15:00:51.000000000 -0500 > +++ linux-2.6.17/arch/um/os-Linux/elf_aux.c 2007-02-23=20 > 15:09:58.000000000 -0500 > @@ -39,6 +39,9 @@ __init void scan_elf_aux( char **envp) > switch ( auxv->a_type ) { > case AT_SYSINFO: > __kernel_vsyscall =3D auxv->a_un.a_val; > + /* See if the page is under TASK_SIZE */ > + if (__kernel_vsyscall <=20 > (unsigned long) envp) > + __kernel_vsyscall =3D 0; > break; > case AT_SYSINFO_EHDR: > vsyscall_ehdr =3D auxv->a_un.a_val; >=20 > -------------------------------------------------------------- > ----------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the=20 > chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge > &CID=3DDEVDEV > _______________________________________________ > User-mode-linux-devel mailing list > Use...@li... > https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel >=20 |
From: Jeff D. <jd...@ad...> - 2007-03-23 21:22:58
|
On Fri, Mar 23, 2007 at 02:05:42PM -0700, Brock, Anthony - NET wrote: > Is this going into stable or devel? If stable, what version? Also, do > you know what version of the host kernels introduced this behavior? It's in mainline (2.6.21-rc4 now). The mail that you're replying to hopefully will get the fix into 2.6.20.4. > Sorry for all the questions, but I believe this is the bug I've been > waiting on for a while (affecting host kernels greater than 2.6.17, or > something of that nature). Thanks! I believe so too, but more confirmation is always welcome. Jeff -- Work email - jdike at linux dot intel dot com |
From: Jeff D. <jd...@ad...> - 2007-03-23 21:26:52
|
On Fri, Mar 23, 2007 at 02:05:42PM -0700, Brock, Anthony - NET wrote: > Is this going into stable or devel? If stable, what version? I said 2.6.20.4, which just came out, so I guess this will wait until 2.6.20.5. Jeff -- Work email - jdike at linux dot intel dot com |
From: <gr...@su...> - 2007-03-30 20:19:48
|
This is a note to let you know that we have just queued up the patch titled Subject: UML - host VDSO fix to the 2.6.20-stable tree. Its filename is uml-host-vdso-fix.patch A git repo of this tree can be found at http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary >From sta...@li... Fri Mar 23 12:41:21 2007 From: Jeff Dike <jd...@ad...> Date: Fri, 23 Mar 2007 15:37:30 -0400 Subject: UML - host VDSO fix To: st...@ke... Cc: uml-devel <use...@li...> Message-ID: <200...@c2...> Content-Disposition: inline From: Jeff Dike <jd...@ad...> This fixes a problem seen by a number of people running UML on newer host kernels. init would hang with an infinite segfault loop. It turns out that the host kernel was providing a AT_SYSINFO_EHDR of 0xffffe000, which faked UML into believing that the host VDSO page could be reused. However, AT_SYSINFO pointed into the middle of the address space, and was unmapped as a result. Because UML was providing AT_SYSINFO_EHDR and AT_SYSINFO to its own processes, these would branch to nowhere when trying to use the VDSO. The fix is to also check the location of AT_SYSINFO when deciding whether to use the host's VDSO. Signed-off-by: Jeff Dike <jd...@li...> Signed-off-by: Greg Kroah-Hartman <gr...@su...> --- linux-2.6.17.orig/arch/um/os-Linux/elf_aux.c 2007-02-23 15:00:51.000000000 -0500 +++ linux-2.6.17/arch/um/os-Linux/elf_aux.c 2007-02-23 15:09:58.000000000 -0500 @@ -39,6 +39,9 @@ __init void scan_elf_aux( char **envp) switch ( auxv->a_type ) { case AT_SYSINFO: __kernel_vsyscall = auxv->a_un.a_val; + /* See if the page is under TASK_SIZE */ + if (__kernel_vsyscall < (unsigned long) envp) + __kernel_vsyscall = 0; break; case AT_SYSINFO_EHDR: vsyscall_ehdr = auxv->a_un.a_val; _______________________________________________ stable mailing list st...@li... http://linux.kernel.org/mailman/listinfo/stable Patches currently in stable-queue which might be from jd...@ad... are |