From owner-freebsd-current@FreeBSD.ORG Thu Dec 26 14:05:10 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 633AFDD4; Thu, 26 Dec 2013 14:05:10 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 00BD81306; Thu, 26 Dec 2013 14:05:09 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id rBQE509C040903; Thu, 26 Dec 2013 16:05:00 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua rBQE509C040903 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id rBQE50rS040902; Thu, 26 Dec 2013 16:05:00 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 26 Dec 2013 16:05:00 +0200 From: Konstantin Belousov To: Andriy Gapon Subject: Re: latest openjdk7 triggers kernel panic Message-ID: <20131226140500.GM59496@kib.kiev.ua> References: <52BC1B41.2060900@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dtz4emBHhXMjtfBB" Content-Disposition: inline In-Reply-To: <52BC1B41.2060900@FreeBSD.org> User-Agent: Mutt/1.5.22 (2013-10-16) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: Alan Cox , FreeBSD Current , peter@freebsd.org, Marcel Moolenaar , freebsd-java@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 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: Thu, 26 Dec 2013 14:05:10 -0000 --dtz4emBHhXMjtfBB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 26, 2013 at 02:04:17PM +0200, Andriy Gapon wrote: >=20 > I am running FreeBSD based on the head from a few weeks ago, amd64. >=20 > It seems that after a recent upgrade of openjdk7 I consistently get a ker= nel > panic when a java process starts: >=20 > panic: Bad entry start/end for new stack entry > KDB: stack backtrace: > db_trace_self_wrapper() at 0xffffffff803adc9b =3D db_trace_self_wrapper+0= x2b/frame > 0xfffffe02ba6fe6e0 > kdb_backtrace() at 0xffffffff805cbd79 =3D kdb_backtrace+0x39/frame 0xffff= fe02ba6fe790 > panic() at 0xffffffff80597733 =3D panic+0x1a3/frame 0xfffffe02ba6fe810 > vm_map_stack() at 0xffffffff80719f2e =3D vm_map_stack+0x3ce/frame 0xfffff= e02ba6fe8a0 > vm_mmap() at 0xffffffff8071c270 =3D vm_mmap+0x520/frame 0xfffffe02ba6fea30 > sys_mmap() at 0xffffffff8071bad3 =3D sys_mmap+0x303/frame 0xfffffe02ba6fe= af0 > amd64_syscall() at 0xffffffff8074d0c8 =3D amd64_syscall+0x238/frame 0xfff= ffe02ba6febf0 > Xfast_syscall() at 0xffffffff80733e2b =3D Xfast_syscall+0xfb/frame 0xffff= fe02ba6febf0 >=20 > Specifically, new_entry->end !=3D top condition is true. > new_entry->end is consistently greater than top by 3 pages. >=20 > I suspect that java now does some hacky things with its stack and I suspe= ct that > vm_map_simplify_entry() call at the end of vm_map_insert() could be to bl= ame. > Although, the call is guarded by a check: >=20 > 1290 /* > 1291 * It may be possible to merge the new entry with the next a= nd/or > 1292 * previous entries. However, due to MAP_STACK_* being a ha= ck, a > 1293 * panic can result from merging such entries. > 1294 */ > 1295 if ((cow & (MAP_STACK_GROWS_DOWN | MAP_STACK_GROWS_UP)) =3D= =3D 0) > 1296 vm_map_simplify_entry(map, new_entry); >=20 > But that check seems to be defeated by the fact that vm_map_stack() clear= s our > the relevant bits after saving them locally: >=20 > 3335 /* > 3336 * The stack orientation is piggybacked with the cow argumen= t. > 3337 * Extract it into orient and mask the cow argument so that = we > 3338 * don't pass it around further. > 3339 * NOTE: We explicitly allow bi-directional stacks. > 3340 */ > 3341 orient =3D cow & (MAP_STACK_GROWS_DOWN|MAP_STACK_GROWS_UP); > 3342 cow &=3D ~orient; >=20 I provided the following patch yesterday to Peter, after the similar mail. diff --git a/sys/vm/vm_map.c b/sys/vm/vm_map.c index e3842a3..51b60de 100644 --- a/sys/vm/vm_map.c +++ b/sys/vm/vm_map.c @@ -1207,6 +1207,7 @@ charged: } else if ((prev_entry !=3D &map->header) && (prev_entry->eflags =3D=3D protoeflags) && + (cow & (MAP_ENTRY_GROWS_DOWN | MAP_ENTRY_GROWS_UP)) =3D=3D 0 && (prev_entry->end =3D=3D start) && (prev_entry->wired_count =3D=3D 0) && (prev_entry->cred =3D=3D cred || But there were no core dump available, and I think that your note is also valid. I do not see why cow should be cleared from the stack direction bits. diff --git a/sys/vm/vm_map.c b/sys/vm/vm_map.c index e3842a3..e15e0ca 100644 --- a/sys/vm/vm_map.c +++ b/sys/vm/vm_map.c @@ -3339,7 +3340,6 @@ vm_map_stack(vm_map_t map, vm_offset_t addrbos, vm_si= ze_t max_ssize, * NOTE: We explicitly allow bi-directional stacks. */ orient =3D cow & (MAP_STACK_GROWS_DOWN|MAP_STACK_GROWS_UP); - cow &=3D ~orient; KASSERT(orient !=3D 0, ("No stack grow direction")); =20 if (addrbos < vm_map_min(map) || --dtz4emBHhXMjtfBB Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJSvDeLAAoJEJDCuSvBvK1BmzMP/idHmUFvFRWBzAfi21cDWRSm pD2en4U0dGNCfky8MOCCLQr4bUVvRU64Nbowy/xtwMkoNMPuuTcBEvRT218J5+de RPs3ekx2Ug/Lhc3KhH2gOF6hJKRMqOWZRuSNISZlJMo9j6X/QPPv2SEmw7GPFnTI yad5u8wbkpg7pUciAENA58ibZrNtOB3WgTZTAPqcHjD5QJbp7j3EtsXOTCcYs4d9 AxPKGjbgbZsYjbZFiTH+A4dMOuIHXyi6rQ1A+XuBS0DaBCaQlsKAp91NqGpX7K/+ NAb6Z3a0E00V2yEXIPeNvKInYQUOBcyEIEJVtJSc9NiMW4e4TXQOWV7Z9vNGnpnP 61DMNPelaHz73RI2KS5MziQ+3l+q/Y6SschdyI2MtbV9sb+bGYoWQVsF0+V+4VUe CX5jQhoQ+h1HtjJj1+SH0yg3OcWQOc03b6N17uBU2daFuz8hP/MF+X1s+PH0Cd8k s9d59HOd6/Et7OTpzKB+IM5CfzwDm25eCkgu3vYTRlT8M2wsY6KrjMWdbiKOwe0k vSPLBUrt9XNU8Bc9q1yLK/Q9CwomNYHK+eM007i3ojGYZiqWRUb4u7d5BfcNVVuf S+XtQv7Zd/dmLiZEeVthZDbYHmz+gnes84DHLvMKt33eo9/84g+pER3HHjUo2aHR Bi2kLxBcL5Jyn98r0zYt =YDEG -----END PGP SIGNATURE----- --dtz4emBHhXMjtfBB--