Date: Thu, 26 Dec 2013 16:05:00 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Andriy Gapon <avg@FreeBSD.org> Cc: Alan Cox <alc@FreeBSD.org>, FreeBSD Current <freebsd-current@FreeBSD.org>, peter@freebsd.org, Marcel Moolenaar <marcel@FreeBSD.org>, freebsd-java@FreeBSD.org Subject: Re: latest openjdk7 triggers kernel panic Message-ID: <20131226140500.GM59496@kib.kiev.ua> In-Reply-To: <52BC1B41.2060900@FreeBSD.org> References: <52BC1B41.2060900@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20131226140500.GM59496>