deadlock between g_event and a thread on removing a device.
Kohji Okuno
okuno.kohji at jp.panasonic.com
Wed Jan 23 10:08:04 UTC 2013
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.
More information about the freebsd-current
mailing list