From owner-freebsd-current@FreeBSD.ORG Thu Jun 21 19:58:24 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 8E1B51065674; Thu, 21 Jun 2012 19:58:24 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 0A6461A5A50; Thu, 21 Jun 2012 19:58:19 +0000 (UTC) Message-ID: <4FE37CD2.2060001@FreeBSD.org> Date: Thu, 21 Jun 2012 23:58:10 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120406 Thunderbird/10.0.3 MIME-Version: 1.0 To: "Kenneth D. Merry" References: <20120621042925.GA44903@nargothrond.kdm.org> <4FE3435F.9080400@FreeBSD.org> <20120621164853.GA37027@nargothrond.kdm.org> In-Reply-To: <20120621164853.GA37027@nargothrond.kdm.org> X-Enigmail-Version: 1.4 OpenPGP: id=10C8A17A Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6AD9D85FEEE707AA2A08CEB9" Cc: current@FreeBSD.org Subject: Re: minor GEOM disk API change coming 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: Thu, 21 Jun 2012 19:58:24 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6AD9D85FEEE707AA2A08CEB9 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 21.06.2012 20:48, Kenneth D. Merry wrote: >>> In this case, the GEOM disk class instance has been created by >>> disk_create(), and the taste of the disk is queued in the GEOM >>> event queue. >>> =09 >>> While that event is queued, the da(4) instance goes away. When the >>> open call comes into the da(4) driver, it dereferences the freed >>> (but non-NULL) peripheral pointer provided by GEOM, which results >>> in a panic. >> >> I think this situation is very specific for the GEOM_DISK class, and >> this callback will be less useful for other classes. >> Does g_cancel_event() cannot help you prevent tasting? >=20 > Calling g_cancel_event(), for instance from disk_gone(), would not > completely close the race condition. It can't cancel an event that is > already in progress, and it is possible for the peripheral to go away w= hile > the event is marked in progress but before the taste gets far enough in= to > daopen() to acquire a reference to the peripheral. If i understand correctly your patch, you acquires a reference to the periph and release it when g_destroy_provider finished. What if you will queue some custom event from the disk_gone() that will call cddiskgonecb()? Does it close the race? This event will be executed after the taste completes. --=20 WBR, Andrey V. Elsukov --------------enig6AD9D85FEEE707AA2A08CEB9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBAgAGBQJP43zXAAoJEAHF6gQQyKF6BgYIAIRCyRdlPbq2T9tCZF1znu1W +rX7NVKAP2iEDtqoJTl8d//44LuC+CSQ8R4NHqcqvvXsqLen8mawPK6cyR0SV7Az 4d6LsNkJk0gIxbhsmAMHt2QoCuKPKCuIbe1UpprbryHcckSirp27aRy5HFUCWliM O66uH8x5fJCA/V0+YoOoqbvWlulTgVTdZfas1UbxdbE1leQ5MhBG5ldpLlL0y9R2 Ld/W2JAjg2qt6JLpEhxx3vup+n6H1UeKkqtpwdSW3v+mIGr9gC/wlNvaqyWyHWNL i1KLmGYfCd3YQW48aNeI/Ik3+W/wF69yT8BFz9N3vWrexT2/YaLmAcPrYTCHzWs= =Fs7M -----END PGP SIGNATURE----- --------------enig6AD9D85FEEE707AA2A08CEB9--