Re: [Qemu-devel] [PATCH 0/3] make bh safe with hot-unplug

[liu ping fan]

On Tue, Jun 25, 2013 at 3:53 PM, Paolo Bonzini <address@hidden> wrote:
> Il 25/06/2013 08:32, liu ping fan ha scritto:
>> On Tue, Jun 25, 2013 at 2:24 PM, Paolo Bonzini <address@hidden> wrote:
>>> Il 25/06/2013 19:38, Liu Ping Fan ha scritto:
>>>> This series relies on refcnt of object used by bh callback to run against 
>>>> unplug.
>>>>
>>>> Open issue:
>>>> Another choice may be rcu, but I think some issues are hard to resolve.
>>>> Using rcu, we have two choice:
>>>>   when holding object refcnt, call qemu_bh_delete(); then after grace 
>>>> period, we can release.
>>>>   Or making qemu_bh_delete() sync in the path of DeviceState's 
>>>> finalization.
>>>
>>> What do you mean exactly?  qemu_bh_delete() is async, but it operates on
>>> dynamically-allocated memory.
>>>
>> Before DeviceState is freed, we should make sure the bh is delete, and
>> not related bh is in fly.
>
> The bh need not be deleted.  It just needs to be not-scheduled (easy,
> qemu_bh_delete does that) and not running.
>
Yes, not-scheduled and not running are the only things needed, but not
easy to know.
> The latter part could be the hard one in a multi-threaded context, but I
> think it's up to the device to ensure it.  It doesn't _have_ to be hard.
>  For example, joining the data-plane thread would do that as well.
>
It seems not easy, take consideration of the sequence:
    _bh_delete(), // ensure not scheduled, ie, no further access to DeviceState
    wait for rcu grace period to come, // ensure not running
    free DeviceState in rcu-reclaimer
But  in current code, _delete() can be placed in DeviceState
finalization path(in reclaimer), which means while reclaiming, there
still exist access path to the DeviceState.
On the other hand, pushing _delete() out of  finalization path is not
easy, since we do not what time the DeviceState has done with its bh.

Regards,
Pingfan
> Paolo
>
>>> Paolo
>>>
>>>> but currently, the callers of qemu_bh_delete() can not satisfy any of the 
>>>> two condition.
>>>
>