From owner-freebsd-emulation@FreeBSD.ORG Mon Feb 27 14:40:06 2012 Return-Path: Delivered-To: emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 52549106566B for ; Mon, 27 Feb 2012 14:40:06 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id A51658FC14 for ; Mon, 27 Feb 2012 14:40:05 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q1REdwwS086297; Mon, 27 Feb 2012 16:39:58 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q1REdwBF009069; Mon, 27 Feb 2012 16:39:58 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q1REdwMk009068; Mon, 27 Feb 2012 16:39:58 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 27 Feb 2012 16:39:58 +0200 From: Konstantin Belousov To: Bengt Ahlgren Message-ID: <20120227143958.GG55074@deviant.kiev.zoral.com.ua> References: <20120224142940.GR55074@deviant.kiev.zoral.com.ua> <20120225011228.GB55074@deviant.kiev.zoral.com.ua> <20120227143143.GE55074@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="QMBzfVONVaIN0ukq" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: emulation@freebsd.org Subject: Re: [Bengt Ahlgren] 8.3-PRERELEASE panic in linux emulation X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 14:40:06 -0000 --QMBzfVONVaIN0ukq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 27, 2012 at 03:35:54PM +0100, Bengt Ahlgren wrote: > Konstantin Belousov writes: >=20 > > On Mon, Feb 27, 2012 at 01:49:28PM +0100, Bengt Ahlgren wrote: > >> Konstantin Belousov writes: > >>=20 > >> > On Fri, Feb 24, 2012 at 09:55:31PM +0100, Bengt Ahlgren wrote: > >> >> Bengt Ahlgren writes: > >> >>=20 > >> >> > Konstantin Belousov 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 > >> >> >>> 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 provid= e more > >> >> >>> info if needed. > >> >> >>>=20 > >> >> >>> Bengt > >> >> >>>=20 > >> >> >>> FreeBSD xx.yy.zz 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #13 r231= 999: Wed Feb 22 21:01:38 CET 2012 bengta@P142.sics.se:/usr/obj/usr/src/= sys/P142-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,c5d6b6= 00,...) at db_trace_self_wrapper+0x26 > >> >> >>> kdb_backtrace(c0919061,c09b49a0,c0900251,e7481910,e7481910,...)= at kdb_backtrace+0x2a > >> >> >>> panic(c0900251,c0941cab,c5c246e8,1,1,...) at panic+0xaf > >> >> >>> trap_fatal(c0670d02,0,e7481964,80400,c5c24580,...) at trap_fata= l+0x353 > >> >> >>> trap_pfault(e74819cc,bfbfe190,c5c24580,202,c5cecac0,...) at tra= p_pfault+0x87 > >> >> >>> trap(e7481a2c) at trap+0x453 > >> >> >>> calltrap() at calltrap+0x6 > >> >> >>> --- trap 0xc, eip =3D 0xc50b396c, esp =3D 0xe7481a6c, ebp =3D 0= xe7481a90 --- > >> >> >>> elf_linux_fixup(e7481c0c,e7481b98,c065ca92,c60ffce8,100000,...)= at elf_linux_fixup+0x33c > >> >> >>> kern_execve(c5c24580,e7481c3c,0,8112710,8116cd8,...) at kern_ex= ecve+0x7d6 > >> >> >>> 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_= shutdown.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=3D3217022= 972) at /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/i38= 6/i386/trap.c:562 > >> >> >>> #6 0xc089bedc in calltrap () at /usr/src/sys/i386/i386/excepti= on.s:168 > >> >> >>> #7 0xc50b396c in elf_linux_fixup (stack_base=3D0xe7481c0c, img= p=3D0xe7481b98) at /usr/src/sys/modules/linux/../../i386/linux/linux_sysvec= .c:288 > >> >> >>> #8 0xc05ac636 in kern_execve (td=3D0xc5c24580, args=3D0xe7481c= 3c, mac_p=3D0x0) at /usr/src/sys/kern/kern_exec.c:551 > >> >> >>> #9 0xc50ab387 in linux_execve (td=3D0xc5c24580, args=3D0xe7481= cec) at /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= /exception.s:266 > >> >> >>> #12 0x00000033 in ?? () > >> >> >>>=20 > >> >> >> I am not sure if this is the real cause of your panic, but the l= ine from > >> >> >> the backtrace indeed has a bug. Please try the change below. > >> >> >> > >> >> >> diff --git a/sys/i386/linux/linux_sysvec.c b/sys/i386/linux/linu= x_sysvec.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, struc= t image_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, str= uct image_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 r2= 31146 > >> >> > and r231148. If there is no change with your patch I will roll b= ack > >> >> > those to see what happens. > >> > This is very unlikely. fadvise() has nothing to do with image activa= tors. > >> > > >> >>=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 prop= erly ? > >>=20 > >> Yes, it (acroread8) does behave properly with the patch. Have not > >> tested extensively, however. > >>=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 ? > >>=20 > >> Not that I'm aware of. Unless the acroread launch script does this. I > >> don't know how to check this for a running process, but "limits|grep > >> stack" in a regular shell gives me: > >>=20 > >> stacksize 65536 kB > >>=20 > >> Or, do you mean that I can dig that out of the crash dump? If so, I'll > >> need some help with how to. > > > > From the kgdb, frame 8, print the content of td->td_proc->p_limit. >=20 > Is this it? >=20 > (kgdb) frame 8 > #8 0xc05ac636 in kern_execve (td=3D0xc5dc3000, args=3D0xe7535c3c, mac_p= =3D0x0) > at /usr/src/sys/kern/kern_exec.c:551 > 551 (*p->p_sysent->sv_fixup)(&stack_base, imgp); > (kgdb) print td->td_proc->p_limit > $1 =3D (struct plimit *) 0xc5490700 > (kgdb) print *td->td_proc->p_limit > $2 =3D {pl_rlimit =3D {{rlim_cur =3D 9223372036854775807,=20 > rlim_max =3D 9223372036854775807}, {rlim_cur =3D 922337203685477580= 7,=20 > rlim_max =3D 9223372036854775807}, {rlim_cur =3D 536870912,=20 > rlim_max =3D 536870912}, {rlim_cur =3D 67108864, rlim_max =3D 67108= 864}, { > rlim_cur =3D 9223372036854775807, rlim_max =3D 9223372036854775807}= , { > rlim_cur =3D 9223372036854775807, rlim_max =3D 9223372036854775807}= , { > rlim_cur =3D 9223372036854775807, rlim_max =3D 9223372036854775807}= , { > rlim_cur =3D 5547, rlim_max =3D 5547}, {rlim_cur =3D 11095, rlim_ma= x =3D 11095},=20 > {rlim_cur =3D 9223372036854775807, rlim_max =3D 9223372036854775807},= { > rlim_cur =3D 9223372036854775807, rlim_max =3D 9223372036854775807}= , { > rlim_cur =3D 9223372036854775807, rlim_max =3D 9223372036854775807}= , { > rlim_cur =3D 9223372036854775807, rlim_max =3D 9223372036854775807}= },=20 > pl_refcnt =3D 51} Yes, but the stack size is the normal 64MB. Did other linux binaries worked before the patch ? E.g., did the bash started normally ? --QMBzfVONVaIN0ukq Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk9Llb4ACgkQC3+MBN1Mb4iNnwCgoFjELYcKUAQ/4EViRLiY+dIs AHwAnRYM1Mt0bVEtappdoZVdaeG8e4wy =gZvC -----END PGP SIGNATURE----- --QMBzfVONVaIN0ukq--