From owner-freebsd-current@FreeBSD.ORG Tue Sep 2 18:44:39 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C63E91065675 for ; Tue, 2 Sep 2008 18:44:39 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id 442B78FC1A for ; Tue, 2 Sep 2008 18:44:39 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1Kaarl-0002vb-5j; Tue, 02 Sep 2008 21:44:37 +0300 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m82IiUwL022379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Sep 2008 21:44:30 +0300 (EEST) (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.2/8.14.2) with ESMTP id m82IiUFX054967; Tue, 2 Sep 2008 21:44:30 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m82IiUM3054966; Tue, 2 Sep 2008 21:44:30 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 2 Sep 2008 21:44:30 +0300 From: Kostik Belousov To: Adam Jacob Muller Message-ID: <20080902184429.GB2038@deviant.kiev.zoral.com.ua> References: <20080830183804.GG2038@deviant.kiev.zoral.com.ua> <20080830195844.GI2038@deviant.kiev.zoral.com.ua> <20080831071618.GK2038@deviant.kiev.zoral.com.ua> <20080831091639.GM2038@deviant.kiev.zoral.com.ua> <80861bfa0809010733h47580d3evb3eb68c972a2bb25@mail.gmail.com> <20080901145315.GU2038@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4rh8KwHgidtw24lr" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 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 X-Virus-Scanned: mail.terabit.net.ua 1Kaarl-0002vb-5j 0aa25621ca5a7c5469071f0727456f72 X-Terabit: YES Cc: freebsd-current@freebsd.org, Vyacheslav Bocharov Subject: Re: __tls_get_addr problem with recent current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2008 18:44:39 -0000 --4rh8KwHgidtw24lr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 02, 2008 at 02:41:08PM -0400, Adam Jacob Muller wrote: >=20 > On Sep 1, 2008, at 10:53 AM, Kostik Belousov wrote: >=20 > >On Mon, Sep 01, 2008 at 05:33:37PM +0300, Vyacheslav Bocharov wrote: > >>I have similar problem in 7-STABLE (from 1 sep): > >>32bit application exec 64application and we have an core dump: > >> > >># gdb fw.sh fw.sh.core > >>GNU gdb 6.1.1 [FreeBSD] > >>Copyright 2004 Free Software Foundation, Inc. > >>GDB is free software, covered by the GNU General Public License, =20 > >>and you are > >>welcome to change it and/or distribute copies of it under certain > >>conditions. > >>Type "show copying" to see the conditions. > >>There is absolutely no warranty for GDB. Type "show warranty" for =20 > >>details. > >>This GDB was configured as "amd64-marcel-freebsd"... > >>Core was generated by `fw.sh'. > >>Program terminated with signal 11, Segmentation fault. > >>Reading symbols from /usr/lib/libstdc++.so.6...done. > >>Loaded symbols for /usr/lib/libstdc++.so.6 > >>Reading symbols from /lib/libm.so.5...done. > >>Loaded symbols for /lib/libm.so.5 > >>Reading symbols from /lib/libgcc_s.so.1...done. > >>Loaded symbols for /lib/libgcc_s.so.1 > >>Reading symbols from /lib/libc.so.7...done. > >>Loaded symbols for /lib/libc.so.7 > >>Reading symbols from /libexec/ld-elf.so.1...done. > >>Loaded symbols for /libexec/ld-elf.so.1 > >>#0 0x0000000800507483 in __tls_get_addr () from /libexec/ld-elf.so.1 > >>(gdb) bt > >>#0 0x0000000800507483 in __tls_get_addr () from /libexec/ld-elf.so.1 > >>#1 0x0000000800ad8892 in _pthread_mutex_init_calloc_cb () from > >>/lib/libc.so.7 > >>#2 0x0000000800ada35f in malloc () from /lib/libc.so.7 > >>#3 0x00000008007050ad in operator new () from /usr/lib/libstdc+=20 > >>+.so.6 > >>#4 0x00000008006b5f21 in std::string::_Rep::_S_create () > >> from /usr/lib/libstdc++.so.6 > >>#5 0x00000008006b6ca5 in std::string::_S_copy_chars () > >> from /usr/lib/libstdc++.so.6 > >>#6 0x00000008006b6dc2 in std::basic_string >>std::char_traits, > >>std::allocator >::basic_string () from /usr/lib/libstdc++.so.6 > >>#7 0x00000000004021ec in __static_initialization_and_destruction_0 ( > >> __initialize_p=3D1, __priority=3D65535) at CCmdLine.cpp:16 > >>#8 0x00000000004026c3 in global constructors keyed to cmdlist () > >> at CCmdLine.cpp:177 > >>#9 0x00000000004033a2 in __do_global_ctors_aux () > >>#10 0x000000000040113e in _init () > >>#11 0x0000000800b2b0c0 in __cxa_atexit () from /lib/libc.so.7 > >>#12 0x00000000004014e8 in _start () > >>#13 0x000000080052c000 in ?? () > >> > >>I tried your patch but nothing changed. > >Exactly which patch ? There were three, one of which caused immediate > >panic. I put the patches at > >http://people.freebsd.org/~kib/misc/fsbase.1.patch > >http://people.freebsd.org/~kib/misc/fsbase.2.patch > > > >Could you, please, try both and report the results ? > >And, isolated test case, as several C files or recipe to reproduce > >this with base system, would be ideal. > > > >> > >>2008/8/31 Kostik Belousov > >> > >>>On Sun, Aug 31, 2008 at 10:16:18AM +0300, Kostik Belousov wrote: > >>>>On Sat, Aug 30, 2008 at 02:03:00PM -0700, Artem Belevich wrote: > >>>>>With the new patch kernel has crashed as soon as I ran i386 app, > >>>>>though the crash happened within in-kernel thread g_up: > >>>>> > >>>>>Fatal trap 12: page fault while in kernel mode > >>>>>cpuid =3D 2; apic id =3D 02 > >>>>>fault virtual address =3D 0x20 > >>>>>fault code =3D supervisor read data, page not present > >>>>>instruction pointer =3D 0x8:0xffffffff804a821f > >>>>>stack pointer =3D 0x10:0xffffffffac280b60 > >>>>>frame pointer =3D 0x10:0x0 > >>>>>code segment =3D base 0x0, limit 0xfffff, type 0x1b > >>>>> =3D DPL 0, pres 1, long 1, def32 0, gran 1 > >>>>>processor eflags =3D resume, IOPL =3D 0 > >>>>>current process =3D 3 (g_up) > >>>>>trap number =3D 12 > >>>>>panic: page fault > >>>>>cpuid =3D 2 > >>>>>Uptime: 37s > >>>>>Physical memory: 8169 MB > >>>>>Dumping 380 MB: 365 349 333 317 301 285 269 253 237 221 205 189 =20 > >>>>>173 > >>>>>157 141 125 109 93 77 61 45 29 13 > >>>>Could you, please, show me the disassembled code around the faulted > >>>>%rip ? > >>> > >>>No need, it seems I found the problem. I trashed the %rdx that =20 > >>>contains > >>>the third cpu_switch argument. Please, try the updated patch. > >>> > >>>Thanks for the testing ! > >>> > >>>diff --git a/sys/amd64/amd64/cpu_switch.S b/sys/amd64/amd64/=20 > >>>cpu_switch.S > >>>index f34b0cc..03f0eca 100644 > >>>--- a/sys/amd64/amd64/cpu_switch.S > >>>+++ b/sys/amd64/amd64/cpu_switch.S > >>>@@ -249,6 +249,12 @@ store_seg: > >>>1: movl %ds,PCB_DS(%r8) > >>> movl %es,PCB_ES(%r8) > >>> movl %fs,PCB_FS(%r8) > >>>+ movq %rdx,%r11 > >>>+ movl $MSR_FSBASE,%ecx > >>>+ rdmsr > >>>+ shlq $32,%rdx > >>>+ leaq (%rax,%rdx),%r9 > >>>+ movq %r11,%rdx > >>> jmp done_store_seg > >>>2: movq PCB_GS32P(%r8),%rax > >>> movq (%rax),%rax > >>> > >> > >> > >> > >>--=20 > >>Vyacheslav Bocharov >=20 >=20 >=20 > Hi, > i have this same issue on recent RELENG_7 (pre and post 7.1-=20 > PRERELEASE), the issue was reproducible by a simple c-app compiled on =20 > 7.x 32-bit >=20 > #include > main() > { > execl("/bin/ls", "/bin/ls", (char *) 0); > } >=20 > this app will segfault rather reliably (but not 100% of the time) =20 > (while true;do ./test; if [ "$?" -gt "0" ];then break; fi; done). >=20 > patch 1 (http://people.freebsd.org/~kib/misc/fsbase.1.patch) fixes the = =20 > issue for me > patch 2 (http://people.freebsd.org/~kib/misc/fsbase.2.patch) does not =20 > though it may mitigate it slightly (cause things to crash less =20 > frequently) Patch below was committed to current, it shall address your issue. diff --git a/sys/amd64/amd64/cpu_switch.S b/sys/amd64/amd64/cpu_switch.S index f34b0cc..a0b11f8 100644 --- a/sys/amd64/amd64/cpu_switch.S +++ b/sys/amd64/amd64/cpu_switch.S @@ -109,8 +109,24 @@ ENTRY(cpu_switch) movq %rsp,PCB_RSP(%r8) movq %rbx,PCB_RBX(%r8) movq %rax,PCB_RIP(%r8) - movq PCB_FSBASE(%r8),%r9 - movq PCB_GSBASE(%r8),%r10 + + /* + * Reread fs and gs bases. Explicit fs segment register load + * by the usermode code may change actual fs base without + * updating pcb_{fs,gs}base. + * + * %rdx still contains the mtx, save %rdx around rdmsr. + */ + movq %rdx,%r11 + movl $MSR_FSBASE,%ecx + rdmsr + shlq $32,%rdx + leaq (%rax,%rdx),%r9 + movl $MSR_KGSBASE,%ecx + rdmsr + shlq $32,%rdx + leaq (%rax,%rdx),%r10 + movq %r11,%rdx =20 testl $PCB_32BIT,PCB_FLAGS(%r8) jnz store_seg diff --git a/sys/amd64/amd64/machdep.c b/sys/amd64/amd64/machdep.c index 06c0803..f3c41f7 100644 --- a/sys/amd64/amd64/machdep.c +++ b/sys/amd64/amd64/machdep.c @@ -734,6 +734,7 @@ exec_setregs(td, entry, stack, ps_strings) pcb->pcb_fsbase =3D 0; pcb->pcb_gsbase =3D 0; critical_exit(); + pcb->pcb_flags &=3D ~(PCB_32BIT | PCB_GS32BIT); load_ds(_udatasel); load_es(_udatasel); load_fs(_udatasel); diff --git a/sys/amd64/ia32/ia32_signal.c b/sys/amd64/ia32/ia32_signal.c index 9e98656..162dcf9 100644 --- a/sys/amd64/ia32/ia32_signal.c +++ b/sys/amd64/ia32/ia32_signal.c @@ -742,5 +742,6 @@ ia32_setregs(td, entry, stack, ps_strings) =20 /* Return via doreti so that we can change to a different %cs */ pcb->pcb_flags |=3D PCB_FULLCTX | PCB_32BIT; + pcb->pcb_flags &=3D ~PCB_GS32BIT; td->td_retval[1] =3D 0; } --4rh8KwHgidtw24lr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAki9iY0ACgkQC3+MBN1Mb4io6ACffUbwirUsrG+W+Tm6p3iiubId 1IsAoM17j/oi6+N2hZlY9TZPzK4WKZhF =YEdn -----END PGP SIGNATURE----- --4rh8KwHgidtw24lr--