On 02/09/2018 02:00 PM, John Ferlan wrote:
>
>
> On 02/09/2018 03:41 AM, Michal Privoznik wrote:
>> On 02/08/2018 04:06 PM, John Ferlan wrote:
>>> [...]
>>>
>>> +static void
>>> +virNWFilterObjPromoteToWrite(virNWFilterObjPtr obj)
>>> +{
>>> +virObjectRWUnlock(obj);
>>> +
On 02/09/2018 03:41 AM, Michal Privoznik wrote:
> On 02/08/2018 04:06 PM, John Ferlan wrote:
>> [...]
>>
>> +static void
>> +virNWFilterObjPromoteToWrite(virNWFilterObjPtr obj)
>> +{
>> +virObjectRWUnlock(obj);
>> +virObjectRWLockWrite(obj);
>> +}
>
> How c
On 02/08/2018 04:06 PM, John Ferlan wrote:
> [...]
>
> +static void
> +virNWFilterObjPromoteToWrite(virNWFilterObjPtr obj)
> +{
> +virObjectRWUnlock(obj);
> +virObjectRWLockWrite(obj);
> +}
How can this not deadlock? This will work only if @obj is locked e
On 02/08/2018 08:30 AM, Daniel P. Berrangé wrote:
On Thu, Feb 08, 2018 at 02:13:58PM +0100, Michal Privoznik wrote:
On 02/06/2018 08:20 PM, John Ferlan wrote:
Unlike it's counterparts, the nwfilter object code needs to be able
to support recursive read locks while processing and checking new
fi
[...]
+static void
+virNWFilterObjPromoteToWrite(virNWFilterObjPtr obj)
+{
+virObjectRWUnlock(obj);
+virObjectRWLockWrite(obj);
+}
>>>
>>> How can this not deadlock? This will work only if @obj is locked exactly
>>> once. But since we allow recursive locks any
On 02/08/2018 02:32 PM, John Ferlan wrote:
>
>
> On 02/08/2018 08:13 AM, Michal Privoznik wrote:
>> On 02/06/2018 08:20 PM, John Ferlan wrote:
>>> Unlike it's counterparts, the nwfilter object code needs to be able
>>> to support recursive read locks while processing and checking new
>>> filters
[...]
>>> }
>>>
>>>
>>> +static void
>>> +virNWFilterObjPromoteToWrite(virNWFilterObjPtr obj)
>>> +{
>>> +virObjectRWUnlock(obj);
>>> +virObjectRWLockWrite(obj);
>>> +}
>>
>> How can this not deadlock? This will work only if @obj is locked exactly
>> once. But since we allow recursiv
On 02/08/2018 08:13 AM, Michal Privoznik wrote:
> On 02/06/2018 08:20 PM, John Ferlan wrote:
>> Unlike it's counterparts, the nwfilter object code needs to be able
>> to support recursive read locks while processing and checking new
>> filters against the existing environment. Thus instead of usi
On Thu, Feb 08, 2018 at 02:13:58PM +0100, Michal Privoznik wrote:
> On 02/06/2018 08:20 PM, John Ferlan wrote:
> > Unlike it's counterparts, the nwfilter object code needs to be able
> > to support recursive read locks while processing and checking new
> > filters against the existing environment.
On 02/06/2018 08:20 PM, John Ferlan wrote:
> Unlike it's counterparts, the nwfilter object code needs to be able
> to support recursive read locks while processing and checking new
> filters against the existing environment. Thus instead of using a
> virObjectLockable which uses pure mutexes, use t
Unlike it's counterparts, the nwfilter object code needs to be able
to support recursive read locks while processing and checking new
filters against the existing environment. Thus instead of using a
virObjectLockable which uses pure mutexes, use the virObjectRWLockable
and primarily use RWLockRead
11 matches
Mail list logo
