[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 0/3] make bh safe with hot-unplug
From: |
liu ping fan |
Subject: |
Re: [Qemu-devel] [PATCH 0/3] make bh safe with hot-unplug |
Date: |
Wed, 26 Jun 2013 10:59:24 +0800 |
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.
>>>
>
- [Qemu-devel] [PATCH 0/3] make bh safe with hot-unplug, Liu Ping Fan, 2013/06/25
- [Qemu-devel] [PATCH 1/3] QEMUBH: introduce canceled member for bh, Liu Ping Fan, 2013/06/25
- [Qemu-devel] [PATCH 2/3] QEMUBH: pin bh's referring object while scheduling, Liu Ping Fan, 2013/06/25
- [Qemu-devel] [PATCH 3/3] virtio-net: set referred object for virtio net's bh, Liu Ping Fan, 2013/06/25
- Re: [Qemu-devel] [PATCH 0/3] make bh safe with hot-unplug, Paolo Bonzini, 2013/06/25
- Re: [Qemu-devel] [PATCH 0/3] make bh safe with hot-unplug, liu ping fan, 2013/06/25
- Re: [Qemu-devel] [PATCH 0/3] make bh safe with hot-unplug, Paolo Bonzini, 2013/06/25
- Re: [Qemu-devel] [PATCH 0/3] make bh safe with hot-unplug,
liu ping fan <=
- Re: [Qemu-devel] [PATCH 0/3] make bh safe with hot-unplug, Paolo Bonzini, 2013/06/26
- Re: [Qemu-devel] [PATCH 0/3] make bh safe with hot-unplug, liu ping fan, 2013/06/26
- Re: [Qemu-devel] [PATCH 0/3] make bh safe with hot-unplug, Paolo Bonzini, 2013/06/26
- Re: [Qemu-devel] [PATCH 0/3] make bh safe with hot-unplug, liu ping fan, 2013/06/26
- Re: [Qemu-devel] [PATCH 0/3] make bh safe with hot-unplug, Paolo Bonzini, 2013/06/26
- Re: [Qemu-devel] [PATCH 0/3] make bh safe with hot-unplug, liu ping fan, 2013/06/26
- Re: [Qemu-devel] [PATCH 0/3] make bh safe with hot-unplug, Paolo Bonzini, 2013/06/27