From owner-svn-src-all@FreeBSD.ORG Thu Mar 27 16:23:51 2014 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 82BAA61B; Thu, 27 Mar 2014 16:23:51 +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)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 05D9E623; Thu, 27 Mar 2014 16:23:50 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.8/8.14.8) with ESMTP id s2RGNkfh005254; Thu, 27 Mar 2014 18:23:46 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s2RGNkfh005254 Received: (from kostik@localhost) by tom.home (8.14.8/8.14.8/Submit) id s2RGNkBT005253; Thu, 27 Mar 2014 18:23:46 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 27 Mar 2014 18:23:46 +0200 From: Konstantin Belousov To: Mateusz Guzik Subject: Re: svn commit: r263755 - head/sys/kern Message-ID: <20140327162346.GR21331@kib.kiev.ua> References: <201403252330.s2PNUaei052956@svn.freebsd.org> <5333D70D.7050306@freebsd.org> <20140327083730.GA22942@dft-labs.eu> <5333E581.1000100@freebsd.org> <20140327145819.GA4730@dft-labs.eu> <20140327150512.GB4730@dft-labs.eu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Dx1O6sYEs5STvSrm" Content-Disposition: inline In-Reply-To: <20140327150512.GB4730@dft-labs.eu> User-Agent: Mutt/1.5.23 (2014-03-12) 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 autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, David Xu , Mateusz Guzik X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 16:23:51 -0000 --Dx1O6sYEs5STvSrm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 27, 2014 at 04:05:12PM +0100, Mateusz Guzik wrote: > On Thu, Mar 27, 2014 at 03:58:19PM +0100, Mateusz Guzik wrote: > > On Thu, Mar 27, 2014 at 04:46:57PM +0800, David Xu wrote: > > > On 2014/03/27 16:37, Mateusz Guzik wrote: > > > >On Thu, Mar 27, 2014 at 03:45:17PM +0800, David Xu wrote: > > > >>I think the async process pointer can be cleared when a process exi= ts > > > >>by registering an event handler. please see attached patch. > > > >> > > > > > > > >Sure, but I'm not very fond of this solution. > > > > > > > >This is a rather obscure bug you wont hit unless you explicitly try, > > > >and even then you need root privs by default. > > > > > > > OK, but I don't like the bug exists in kernel. It is not obscure for = me, > > > I can run "shutdown now" command, and insert a device, and then the > > > kernel will write garbage data into freed memory space. > > >=20 > >=20 > > Not sure what you mean. devd does not use this feature, and even if it > > did async_proc is cleared on close, which happens while signal delivery > > is still legal. > >=20 > > That said, you are not going to encounter this bug unless you code > > something up to specifically trigger it. > >=20 > > fwiw, I think we could axe this feature if there was no way to fix it > > without introducing a check for every process. > >=20 > > > >As such writing a callback function which will be executed for all e= xiting > > > >processes seems unjustified for me. > > > > > > > >Ideally we would get some mechanism which would allow to register > > > >callbacks for events related to given entity. Then it could be used = to > > > >provide a "call this function when process p exits", amongst other t= hings. > > > > > > >=20 > > > Yes, but the callback itself is cheap enough and is not worth to be > > > per-entity entry. > > >=20 > >=20 > > There is other code in the kernel which would benefit from such > > functionality - dev/syscons/scmouse, dev/vt/vt_core.c, aio and possibly > > more. > >=20 > > As such I think this is worth pursuing. > >=20 >=20 > We can hack around this one the way the other code is doing - apart from > from proc pointer you store pid and then compare result of pfind(pid). >=20 > This is still buggy as both proc and pid pointer can be recycled and end > up being the same (but you have an entrirely new process). >=20 > However, then in absolutely worst cae you send SIGIO to incorrect > process, always an existing process so no more corruption. >=20 > Would you be ok with such hack for the time being? Isn't p_sigiolist and fsetown(9) already provide the neccessary registration and cleanup on the process exit ? The KPI might require some generalizatio= n, but I think that the mechanism itself is enough. --Dx1O6sYEs5STvSrm Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJTNFCRAAoJEJDCuSvBvK1BRQ4P/1PXSIzOOABjwrDZbHzOLnd5 AlE/LbJ73FNQ3QXyQL0Lk/iLMvpgkwiTjkf37XoYb+CoUZlohRajeB1YB1FCHh10 Lkd+AAYd1lGa8s6ZdAn+luiIpO8TaPjKKFj2rkpju2n9OuiK6uCjsYopTu90UMAF SHp7qAjVcIBxguKOJaOiFCOhW+Amg0lWq1lbG+yawVr6lZW5kraQlxQQQmnRCm41 8cOoekkWbRcRV39sAO+FN1WF2JkVYCkaxk1Z5XvBEJT38piOVHMAJrFfkDy1ASOY OzCFEi8Z64E4I2JunjvU8LKMrQoLhaX8emA7sKawa2t66MGlycdptEyFN+wFUrvM Rkikg5Qc9WuHSeEgYVTVSerpxXI7miKCa2EJJb2qH76a7NWbLpZJ3fCbZAxnYVnm IBTgoPmXAbivCqr0Dnk/O3afu0UdrGbJPwEWx8IlLL0iHl7UBz/OS3k28vU7G2Yj 33KkgDSKEWYFLkzku1kf8cGVKGuAKManKbPN31s5vPw6rZcSixRrJgP5o3TQPYiP 4EL5PJUmGYEOgK+LNezSAQ5bAqaHoH5RbpiCMWJ61SWT6ZzpFmkFHnkvwrAaY4GH k05k1bUppDnUrt7LESD9RbTBqft2dpLpdlIkz00hXLt4fqBdaQ/H5S2/viVan3zp EJXqOieP3hFkuKW2h3Nk =AwI1 -----END PGP SIGNATURE----- --Dx1O6sYEs5STvSrm--