From owner-freebsd-current@FreeBSD.ORG Wed Jan 23 09:54:24 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9DED8F72; Wed, 23 Jan 2013 09:54:24 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id E2DCE6C2; Wed, 23 Jan 2013 09:54:23 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r0N9sGm1049005; Wed, 23 Jan 2013 11:54:16 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r0N9sGm1049005 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r0N9sEHv049004; Wed, 23 Jan 2013 11:54:14 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 23 Jan 2013 11:54:14 +0200 From: Konstantin Belousov To: Kohji Okuno Subject: Re: deadlock between g_event and a thread on removing a device. Message-ID: <20130123095414.GU2522@kib.kiev.ua> References: <20130118.144538.1860198911942517633.okuno.kohji@jp.panasonic.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8MIuRhPDBHHz1F6y" Content-Disposition: inline In-Reply-To: <20130118.144538.1860198911942517633.okuno.kohji@jp.panasonic.com> User-Agent: Mutt/1.5.21 (2010-09-15) 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: ae@freebsd.org, freebsd-current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 23 Jan 2013 09:54:24 -0000 --8MIuRhPDBHHz1F6y Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 18, 2013 at 02:45:38PM +0900, Kohji Okuno wrote: > Hi, >=20 > When I removed a device (ex. /dev/da0), I have encounterd a > dead-lock between ``g_event'' thread and a thread that is opening > device file (I call this thread as A). >=20 > Would you refer the following? >=20 > When the device is removed between dev_refthread() and g_dev_open(), > thread A incremented dev->si_threadcount, but can't acquire > topology_lock. >=20 > On the other hand, g_event is waiting to set dev->si_threadcount to 0 > with topology_lock. >=20 > Regards, > Kohji Okuno >=20 >=20 > <<< Thread A >>> > ... > devfs_open() > { > ... > dsw =3D dev_refthread(dev, &ref); <=3D increment dev->si_threadcount > ... > error =3D dsw->d_open(...); <=3D call g_dev_open() > ... > dev_relthread(dev, ref); <=3D decrement dev->si_threadcount > } >=20 > g_dev_open() > { > ... > g_topology_lock(); <=3D Thread A couldn't acquire=20 > ... topology_lock. > } >=20 > <<< g_event >>> > g_run_events() > { > ... > g_topology_lock(); <=3D g_event acuired topology_lock here. > ... > one_event() > ... > } >=20 > one_event() > g_orphan_register() > g_dev_orphan() > destroy_dev() > destroy_dev() > destroy_devl() > { > ... > while (dev->si_threadcount !=3D 0) { <=3D this count was incremented by= Thread A > /* Use unique dummy wait ident */ > msleep(&csw, &devmtx, PRIBIO, "devdrn", hz / 10); > } > ... > } Yes, you are absolutely right. I believe there were some patches floating around which changed the destroy_dev() call in the g_dev_orphan() to destroy_dev_sched(). I do not remember who was the author. My reply was that naive substitution of the destroy_dev() to destroy_dev_sched() is racy, because some requests might still come in after the call to destroy_dev_sched(). Despite destroy_dev_sched() setting the CDP_SCHED_DTR flag on the devfs node, some thread might already entered the cdevsw method. I do not believe that there was further progress there. --8MIuRhPDBHHz1F6y Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQ/7NFAAoJEJDCuSvBvK1BudYP/j4awPTFvuXcmeShTVrIRgix guS7LxPnWNAFJztRiKSu1SiYGFY0lwyrAru9+L/pPaUwPsiHFGTwCHeqcXQIRv8l mD3+8vx1M6ynXeVf39ACVB1Fxro5W9gyrj7f/z04sgjDY0vg4q0hswBEyZ0N1ROU TF69g1De2GLfgOhm5SnXzmhPRbrcA4vJV5z35nmE1FV2uhyvGNmVrQlHSKepSq5C xI7Pr/hpStJu1sFTt6aNlJAMjqQnvdzXDkYAq5QfQRzVeXionyVDv3rDgL3PoMJg pGvsc4CsMqozBhNF0Bk2kHVSyXpXA/J+/oJutGarIEPyHJDj8xcJG6UG+2N7KyTU O8KhRDj2k+LfwHzk3Rbl7SuWGyKGl47zmBrjrEFK7zavVHpxjN7ox5M/68WAcTCE 0c26MuMWTZ7PTRe/zibQTW2I0v1EjmlWk4S5eM1dZSn1STtcm6dJ2fF0dYClm1rY zt4yeASiAPSl3gVuNL8tGA6KYbkihTei0Fdhvbd7aSmpYoZ6yfoTiU6BOIIyueiE 40T5Bs0NEEPp2BtLEXRelW8fIvgCVegwrPLwIesVHA7D9J7omS+BPTyJZanFxoHc AobMYzxk/8B22CkPtswCtJb51QcRts29xPPolJ56lFG0ObUMl11M0lIvsP2rmzd9 ZaK+3a7WiezyXjSqbReO =xJf+ -----END PGP SIGNATURE----- --8MIuRhPDBHHz1F6y--