Re: [Qemu-devel] [PATCH v2 4/4] timer: make qemu_clock_enable sync between disable and timer's cb

[liu ping fan]

On Sun, Aug 18, 2013 at 10:54 PM, Paolo Bonzini <address@hidden> wrote:
> Il 14/08/2013 02:34, liu ping fan ha scritto:
>> On Tue, Aug 13, 2013 at 10:53 PM, Paolo Bonzini <address@hidden> wrote:
>>>
>>> Il 13/08/2013 07:43, Liu Ping Fan ha scritto:
>>>> After disabling the QemuClock, we should make sure that no QemuTimers
>>>> are still in flight. To implement that with light overhead, we resort
>>>> to QemuEvent. The caller of disabling will wait on QemuEvent of each
>>>> timerlist.
>>>>
>>>> Note, qemu_clock_enable(foo,false) can _not_ be called from timer's cb.
>>>> And the callers of qemu_clock_enable() should be sync by themselves,
>>>> not protected by this patch.
>>>>
>>>> Signed-off-by: Liu Ping Fan <address@hidden>
>>>> ---
>>>>  include/qemu/timer.h |  4 ++++
>>>>  qemu-timer.c         | 53 
>>>> +++++++++++++++++++++++++++++++++++++++++++++++++++-
>>>>  2 files changed, 56 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/include/qemu/timer.h b/include/qemu/timer.h
>>>> index 829c005..2b755c9 100644
>>>> --- a/include/qemu/timer.h
>>>> +++ b/include/qemu/timer.h
>>>> @@ -184,6 +184,10 @@ void qemu_clock_notify(QEMUClockType type);
>>>>   * @enabled: true to enable, false to disable
>>>>   *
>>>>   * Enable or disable a clock
>>>> + * Disabling the clock will wait for related timerlists to stop
>>>> + * executing qemu_run_timers.  Thus, this functions should not
>>>> + * be used from the callback of a timer that is based on @clock.
>>>> + * Doing so would cause a deadlock.
>>>>   */
>>>>  void qemu_clock_enable(QEMUClockType type, bool enabled);
>>>>
>>>> diff --git a/qemu-timer.c b/qemu-timer.c
>>>> index 5b9a722..8b32e92 100644
>>>> --- a/qemu-timer.c
>>>> +++ b/qemu-timer.c
>>>> @@ -48,6 +48,12 @@ typedef struct QEMUClock {
>>>>      QLIST_HEAD(, QEMUTimerList) timerlists;
>>>>
>>>>      NotifierList reset_notifiers;
>>>> +    /* While the reader holds this lock, it may block on events_list.
>>>> +     * So the modifier should be carefuly not to reset the event before
>>>> +     * holding this lock. Otherwise, deadlock.
>>>> +     */
>>>> +    QemuMutex events_list_lock;
>>>> +    GList *events_list;
>>>
>>> No need for a separate list.  Just use the timerlists list; if
>>> events_list needs a lock, timerlists needs one too.
>>>
>> Here is a ugly pattern issue, we hold events_list_lock and wait for
>> QemuEvent set. If the modifier reset the QemuEvent and then try to
>> hold the events_list_lock, then _deadlock_.  To eliminate the
>> possibility, using  @events_list_lock, and you can see the modifier
>> can not reset QemuEvent while trying to own the lock. On the other
>> handle, if using lock on timerlists, since many entrance to access the
>> lock, we are not sure of avoiding deadlock
>
> But does timerlists need a lock, or does the BQL suffice?  If it
> doesn't, there is no need for events_list_lock either.  Is
> qemu_clock_enable called outside the BQL?
>
Currently, no such guarantee based on BQL. But if we enforce that an
backend thread holds BQL before it cleans up resources, we can resort
to BQL. (so document this, and save the events_list_lock?)

Regards,
Pingfan