Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 27 Feb 2012 16:39:58 +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:  <20120227143958.GG55074@deviant.kiev.zoral.com.ua>
In-Reply-To: <uh7obskbayd.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> <20120225011228.GB55074@deviant.kiev.zoral.com.ua> <uh762es5tlz.fsf@P142.sics.se> <20120227143143.GE55074@deviant.kiev.zoral.com.ua> <uh7obskbayd.fsf@P142.sics.se>

next in thread | previous in thread | raw e-mail | index | archive | help

--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 <kostikbel@gmail.com> writes:
>=20
> > On Mon, Feb 27, 2012 at 01:49:28PM +0100, Bengt Ahlgren wrote:
> >> Konstantin Belousov <kostikbel@gmail.com> writes:
> >>=20
> >> > 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 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--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120227143958.GG55074>