From owner-freebsd-current@freebsd.org Wed Dec 16 15:25:03 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 77032A488A8 for ; Wed, 16 Dec 2015 15:25:03 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3CA641ABE for ; Wed, 16 Dec 2015 15:25:02 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from [78.35.181.63] (helo=fabiankeil.de) by smtprelay05.ispgateway.de with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.84) (envelope-from ) id 1a9Di2-0005E6-2V; Wed, 16 Dec 2015 16:09:42 +0100 Date: Wed, 16 Dec 2015 16:09:17 +0100 From: Fabian Keil To: Konstantin Belousov Cc: FreeBSD Current Subject: Re: fork_findpid() - Fatal trap 12: page fault while in kernel mode Message-ID: <20151216160917.2a6a51ba@fabiankeil.de> In-Reply-To: <20151216121000.GV3625@kib.kiev.ua> References: <20151215174238.2d7cc3bb@fabiankeil.de> <20151216104227.GS3625@kib.kiev.ua> <20151216122116.09e1b27d@fabiankeil.de> <20151216121000.GV3625@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/qcxsTHExtkBcbkztzNHEMaN"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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: Wed, 16 Dec 2015 15:25:03 -0000 --Sig_/qcxsTHExtkBcbkztzNHEMaN Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Konstantin Belousov wrote: > On Wed, Dec 16, 2015 at 12:21:16PM +0100, Fabian Keil wrote: > > Konstantin Belousov wrote: =20 > > > It is the values of *p and *(p->p_pgrp) that are needed, from the fra= me 8. =20 > >=20 > > Unfortunately it's not available and apparently I removed the attempts > > to get it from the previous output. =20 >=20 > > allproc is available and the first one matches lastpid and has an inval= id > > p_pgrp, but due to trypid being optimized out as well, it's not obvious > > (to me) that it's the right process. =20 >=20 > p_suspcount =3D 0, p_xthread =3D 0xfffff801162819a0, p_boundary_count =3D= 0, p_pendingcnt =3D 0, p_itimers =3D 0x0, p_procdesc =3D 0x0, p_treeflag = =3D 0, p_magic =3D 3203398350, p_osrel =3D 1100090,=20 > > p_comm =3D 0xfffff800304df3c4 "privoxy", =20 > p_pgrp =3D 0x618b0080, >=20 > > I've changed p's declaration to static so hopefully its value will > > be available the next time the panic occurs, but it may take a while > > until that happens. =20 >=20 > From the state of the process you provided, it is a new (zigote) of the > forking process, which was already linked into allproc list. Also, > it seems that bzero part of the forking procedure was finished, but bcopy > was not yet. The p_pgrp cannot be a pointer, it is not yet initialized. >=20 > There, we have at least one issue, since zigote is linked before the > p_pgrp is initialized, and the proctree/allproc locks are dropped. > As result, fork_findpid() accesses memory with undefined content. >=20 > It seems that the least morbid solution is to slightly extend the scope > of the allproc lock in do_fork(), to prevent fork_findpid() from working > while we did not finished copying data from old to new process. Thanks. I'm currently testing the patch on three systems but it may take a = while ... Fabian --Sig_/qcxsTHExtkBcbkztzNHEMaN Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlZxfp4ACgkQBYqIVf93VJ3IaQCbBDUU/tcTDciXRuFpUUoM8heq fEsAnRFnq5ztpJDJkIjOKAckqljFrV5x =EI03 -----END PGP SIGNATURE----- --Sig_/qcxsTHExtkBcbkztzNHEMaN--