Date: Sat, 25 Feb 2012 03:12:28 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Bengt Ahlgren <bengta@sics.se> Cc: emulation@freebsd.org Subject: Re: [Bengt Ahlgren] 8.3-PRERELEASE panic in linux emulation Message-ID: <20120225011228.GB55074@deviant.kiev.zoral.com.ua> In-Reply-To: <uh7fwe054u4.fsf@P142.sics.se> References: <uh762ewxvpv.fsf@P142.sics.se> <20120224142940.GR55074@deviant.kiev.zoral.com.ua> <uh739a0w39k.fsf@P142.sics.se> <uh7fwe054u4.fsf@P142.sics.se>
next in thread | previous in thread | raw e-mail | index | archive | help
--+qlyv6FHKYYAux7U Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 24, 2012 at 09:55:31PM +0100, Bengt Ahlgren wrote: > Bengt Ahlgren <bengta@sics.se> writes: >=20 > > Konstantin Belousov <kostikbel@gmail.com> writes: > > > >> On Fri, Feb 24, 2012 at 01:27:24PM +0100, Bengt Ahlgren wrote: > >>> Hello! > >>>=20 > >>> Perhaps emulation@ is a better place to report this problem? > >>>=20 > >>> Bengt > >>>=20 > >> > >>> From: Bengt Ahlgren <bengta@sics.se> > >>> To: stable@freebsd.org > >>> Subject: 8.3-PRERELEASE panic in linux emulation > >>> Date: Thu, 23 Feb 2012 17:26:32 +0100 > >>>=20 > >>> Hi! > >>>=20 > >>> I get a consistent panic when starting acroread after updating to > >>> 8.3-PRERELEASE. An 8.2-STABLE from Feb 4th was OK. Can provide more > >>> info if needed. > >>>=20 > >>> Bengt > >>>=20 > >>> FreeBSD xx.yy.zz 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #13 r231999: W= ed Feb 22 21:01:38 CET 2012 bengta@P142.sics.se:/usr/obj/usr/src/sys/P1= 42-82 i386 > >>>=20 > >>> Fatal trap 12: page fault while in kernel mode > >>> fault virtual address =3D 0xbfbfdffc > >>> fault code =3D supervisor write, page not present > >>> instruction pointer =3D 0x20:0xc50b396c > >>> stack pointer =3D 0x28:0xe7481a6c > >>> frame pointer =3D 0x28:0xe7481a90 > >>> code segment =3D base 0x0, limit 0xfffff, type 0x1b > >>> =3D DPL 0, pres 1, def32 1, gran 1 > >>> processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > >>> current process =3D 1997 (bash) > >>> trap number =3D 12 > >>> panic: page fault > >>> KDB: stack backtrace: > >>> db_trace_self_wrapper(c091af2a,70797420,78302065,a0d6231,c5d6b600,...= ) at db_trace_self_wrapper+0x26 > >>> kdb_backtrace(c0919061,c09b49a0,c0900251,e7481910,e7481910,...) at kd= b_backtrace+0x2a > >>> panic(c0900251,c0941cab,c5c246e8,1,1,...) at panic+0xaf > >>> trap_fatal(c0670d02,0,e7481964,80400,c5c24580,...) at trap_fatal+0x353 > >>> trap_pfault(e74819cc,bfbfe190,c5c24580,202,c5cecac0,...) at trap_pfau= lt+0x87 > >>> trap(e7481a2c) at trap+0x453 > >>> calltrap() at calltrap+0x6 > >>> --- trap 0xc, eip =3D 0xc50b396c, esp =3D 0xe7481a6c, ebp =3D 0xe7481= a90 --- > >>> elf_linux_fixup(e7481c0c,e7481b98,c065ca92,c60ffce8,100000,...) at el= f_linux_fixup+0x33c > >>> kern_execve(c5c24580,e7481c3c,0,8112710,8116cd8,...) at kern_execve+0= x7d6 > >>> linux_execve(c5c24580,e7481cec,c,c,c,...) at linux_execve+0xa7 > >>> syscall(e7481d28) at syscall+0x372 > >>> Xint0x80_syscall() at Xint0x80_syscall+0x21 > >>> --- syscall (11, Linux ELF, linux_execve), eip =3D 0x281e0d4a, esp = =3D 0xbfbfd644, ebp =3D 0xbfbfd7e8 --- > >>>=20 > >>> #0 doadump () at pcpu.h:244 > >>> #1 0xc05de609 in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdo= wn.c:441 > >>> #2 0xc05de84f in panic (fmt=3DVariable "fmt" is not available. > >>> ) at /usr/src/sys/kern/kern_shutdown.c:614 > >>> #3 0xc08b22c3 in trap_fatal (frame=3D0xe7481a2c, eva=3D3217022972) a= t /usr/src/sys/i386/i386/trap.c:981 > >>> #4 0xc08b2357 in trap_pfault (frame=3D0xe7481a2c, usermode=3D0, eva= =3D3217022972) at /usr/src/sys/i386/i386/trap.c:843 > >>> #5 0xc08b3133 in trap (frame=3D0xe7481a2c) at /usr/src/sys/i386/i386= /trap.c:562 > >>> #6 0xc089bedc in calltrap () at /usr/src/sys/i386/i386/exception.s:1= 68 > >>> #7 0xc50b396c in elf_linux_fixup (stack_base=3D0xe7481c0c, imgp=3D0x= e7481b98) at /usr/src/sys/modules/linux/../../i386/linux/linux_sysvec.c:288 > >>> #8 0xc05ac636 in kern_execve (td=3D0xc5c24580, args=3D0xe7481c3c, ma= c_p=3D0x0) at /usr/src/sys/kern/kern_exec.c:551 > >>> #9 0xc50ab387 in linux_execve (td=3D0xc5c24580, args=3D0xe7481cec) a= t /usr/src/sys/modules/linux/../../i386/linux/linux_machdep.c:143 > >>> #10 0xc08b2902 in syscall (frame=3D0xe7481d28) at subr_syscall.c:114 > >>> #11 0xc089bf41 in Xint0x80_syscall () at /usr/src/sys/i386/i386/excep= tion.s:266 > >>> #12 0x00000033 in ?? () > >>>=20 > >> I am not sure if this is the real cause of your panic, but the line fr= om > >> the backtrace indeed has a bug. Please try the change below. > >> > >> diff --git a/sys/i386/linux/linux_sysvec.c b/sys/i386/linux/linux_sysv= ec.c > >> index 7634138..d4e23e1 100644 > >> --- a/sys/i386/linux/linux_sysvec.c > >> +++ b/sys/i386/linux/linux_sysvec.c > >> @@ -227,11 +227,11 @@ linux_fixup(register_t **stack_base, struct imag= e_params *imgp) > >> argv =3D *stack_base; > >> envp =3D *stack_base + (imgp->args->argc + 1); > >> (*stack_base)--; > >> - **stack_base =3D (intptr_t)(void *)envp; > >> + suword(*stack_base, (intptr_t)(void *)envp); > >> (*stack_base)--; > >> - **stack_base =3D (intptr_t)(void *)argv; > >> + suword(*stack_base, (intptr_t)(void *)argv); > >> (*stack_base)--; > >> - **stack_base =3D imgp->args->argc; > >> + suword(*stack_base, imgp->args->argc); > >> return (0); > >> } > >> =20 > >> @@ -286,7 +286,7 @@ elf_linux_fixup(register_t **stack_base, struct im= age_params *imgp) > >> imgp->auxargs =3D NULL; > >> =20 > >> (*stack_base)--; > >> - **stack_base =3D (register_t)imgp->args->argc; > >> + suword(*stack_base, (register_t)imgp->args->argc); > >> return (0); > >> } > >> =20 > > > > Thanks for the response! I will try the patch, but that file has not > > been touched since June 2011. I was suspecting the changes in r231146 > > and r231148. If there is no change with your patch I will roll back > > those to see what happens. This is very unlikely. fadvise() has nothing to do with image activators. >=20 > No panics so far. That patch does indeed seem to solve the problem! I > also verified with going back to the old kernel, which again > consistently paniced. I will commit the change in minutes. Kernel must not access usermode addresses directly. But, does the application that used to panic the system, behave properly ? >=20 > Thanks very much for good work! >=20 > I'm a but puzzled though, because that bug must have been there for > quite some time without triggering the panic. The panic with unpatched kernel looks puzzling. Do you have some non-default stack limit ? Can you look at the resource limit values for the process initiated the panic ? --+qlyv6FHKYYAux7U Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk9INXwACgkQC3+MBN1Mb4iNVgCgz1j2D9K3fO2oUZE9lVUf90lJ jY0An1sN7t24gaED4ys4oYL3fCgb4hFn =1M0W -----END PGP SIGNATURE----- --+qlyv6FHKYYAux7U--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120225011228.GB55074>