Date: Wed, 23 Jan 2013 19:07:54 +0900 (JST) From: Kohji Okuno <okuno.kohji@jp.panasonic.com> To: kostikbel@gmail.com Cc: ae@freebsd.org, freebsd-current@FreeBSD.org, okuno.kohji@jp.panasonic.com Subject: Re: deadlock between g_event and a thread on removing a device. Message-ID: <20130123.190754.558674226904055738.okuno.kohji@jp.panasonic.com> In-Reply-To: <20130123095414.GU2522@kib.kiev.ua> References: <20130118.144538.1860198911942517633.okuno.kohji@jp.panasonic.com> <20130123095414.GU2522@kib.kiev.ua>
index | next in thread | previous in thread | raw e-mail
Hi Konstantin,
Thank you for your comment.
I don't have any solution for this issue.
And when a device is removed suddenly, there are other problems, I think.
> On Fri, Jan 18, 2013 at 02:45:38PM +0900, Kohji Okuno wrote:
>> Hi,
>>
>> 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).
>>
>> Would you refer the following?
>>
>> When the device is removed between dev_refthread() and g_dev_open(),
>> thread A incremented dev->si_threadcount, but can't acquire
>> topology_lock.
>>
>> On the other hand, g_event is waiting to set dev->si_threadcount to 0
>> with topology_lock.
>>
>> Regards,
>> Kohji Okuno
>>
>>
>> <<< Thread A >>>
>> ...
>> devfs_open()
>> {
>> ...
>> dsw = dev_refthread(dev, &ref); <= increment dev->si_threadcount
>> ...
>> error = dsw->d_open(...); <= call g_dev_open()
>> ...
>> dev_relthread(dev, ref); <= decrement dev->si_threadcount
>> }
>>
>> g_dev_open()
>> {
>> ...
>> g_topology_lock(); <= Thread A couldn't acquire
>> ... topology_lock.
>> }
>>
>> <<< g_event >>>
>> g_run_events()
>> {
>> ...
>> g_topology_lock(); <= g_event acuired topology_lock here.
>> ...
>> one_event()
>> ...
>> }
>>
>> one_event()
>> g_orphan_register()
>> g_dev_orphan()
>> destroy_dev()
>> destroy_dev()
>> destroy_devl()
>> {
>> ...
>> while (dev->si_threadcount != 0) { <= 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.
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130123.190754.558674226904055738.okuno.kohji>