[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC PATCH v4 15/15] slirp: use lock to protect the sli
From: |
liu ping fan |
Subject: |
Re: [Qemu-devel] [RFC PATCH v4 15/15] slirp: use lock to protect the slirp_instances |
Date: |
Fri, 19 Apr 2013 14:13:17 +0800 |
On Thu, Apr 18, 2013 at 10:16 PM, Paolo Bonzini <address@hidden> wrote:
>
>> grep'ing for slirp_instances points to more spots that work with that
>> list (QTAILQ_FOREACH, QTAILQ_EMPTY, ...). So the same question here:
>> What are the usage rules? When do I _not_ need it when touching the list
>> of instances, and why?
>>
>> Well, I started reading at the top, but there are more lock-adding
>> patches in this series. And the more locks we have, the higher the
>> probability of ABBA gets. Therefore, please document from the beginning
>> the lock order rules that shall prevent it (which may also be "never
>> take other locks while holding this one" or "never hold other locks when
>> taking this one").
>
slrip->lock is used to protect the frontend and backend to touch
slirp's content at the same time. While slirp_instances_lock is used
to protected the list ops only. For example, when the SlirpState's
refcnt comes to zero(this can not happen with holding slirp->lock),
finalize is called, and finally, slirp_cleanup is called to remove
slrip from the list. The two locks have no overlap.
Regards, Pingfan
> Yeah, the only sane ordering rules should be "hold nothing or just
> the BQL when taking this one". Everything else needs a very good
> justification...
>
Ok, will notice.
Thanks, Pingfan
> Paolo
- Re: [Qemu-devel] [RFC PATCH v4 12/15] slirp: make timeout local, (continued)
[Qemu-devel] [RFC PATCH v4 15/15] slirp: use lock to protect the slirp_instances, Liu Ping Fan, 2013/04/17