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 the virObjectRWLockable and primarily use RWLockRead when obtaining the object lock since RWLockRead locks can be recursively obtained (up to a limit) as long as there's a corresponding unlock.

Since all the object management is within the virnwfilterobj code, we can limit the number of Write locks on the object to very small areas of code to ensure we don't run into deadlock's with other threads and domain code that will check/use the filters (it's a very delicate balance). This limits the write locks to AssignDef and Remove processing.

This patch will introduce a new API virNWFilterObjEndAPI to unlock and deref the object.

This patch introduces two helpers to promote/demote the read/write lock.

Signed-off-by: John Ferlan <jferlan@redhat.com> --- src/conf/virnwfilterobj.c | 193 +++++++++++++++++++++++---------- src/conf/virnwfilterobj.h | 9 +- src/libvirt_private.syms | 3 +- src/nwfilter/nwfilter_driver.c | 15 +-- src/nwfilter/nwfilter_gentech_driver.c | 11 +- 5 files changed, 153 insertions(+), 78 deletions(-)

diff --git a/src/conf/virnwfilterobj.c b/src/conf/virnwfilterobj.c index 87d7e7270..cd52706ec 100644 --- a/src/conf/virnwfilterobj.c +++ b/src/conf/virnwfilterobj.c @@ -34,7 +34,7 @@ VIR_LOG_INIT("conf.virnwfilterobj");

struct _virNWFilterObj { - virMutex lock; + virObjectRWLockable parent;

bool wantRemoved;

@@ -47,27 +47,69 @@ struct _virNWFilterObjList { virNWFilterObjPtr *objs; };

+static virClassPtr virNWFilterObjClass; +static void virNWFilterObjDispose(void *opaque); + + +static int +virNWFilterObjOnceInit(void) +{ + if (!(virNWFilterObjClass = virClassNew(virClassForObjectRWLockable(), + "virNWFilterObj", + sizeof(virNWFilterObj), + virNWFilterObjDispose))) + return -1; + + return 0; +} + +VIR_ONCE_GLOBAL_INIT(virNWFilterObj) +

static virNWFilterObjPtr virNWFilterObjNew(void) { virNWFilterObjPtr obj;

- if (VIR_ALLOC(obj) < 0) + if (virNWFilterObjInitialize() < 0) return NULL;

- if (virMutexInitRecursive(&obj->lock) < 0) { - virReportError(VIR_ERR_INTERNAL_ERROR, - "%s", _("cannot initialize mutex")); - VIR_FREE(obj); + if (!(obj = virObjectRWLockableNew(virNWFilterObjClass))) return NULL; - }

- virNWFilterObjLock(obj); + virObjectRWLockWrite(obj); return obj; }

+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 lock() that happens in the 2nd level must deadlock with this. On the other hand, there's no such case in the code currently. But that doesn't stop anybody from calling PromoteWrite() without understanding its limitations. Maybe the fact that we need recursive lock for NWFilterObj means it's not a good candidate for virObjectRWLocable? It is still a good candidate for virObject though. Or if you want to spend extra time on this, maybe introducing virObjectRecursiveLockable may be worth it (terrible name, I know).

@@ -347,26 +426,39 @@ virNWFilterObjListAssignDef(virNWFilterObjListPtr nwfilters, }

+ /* Get a READ lock and immediately promote to WRITE while we adjust + * data within. */ if ((obj = virNWFilterObjListFindByName(nwfilters, def->name))) {

objdef = obj->def; if (virNWFilterDefEqual(def, objdef)) { + virNWFilterObjPromoteToWrite(obj); virNWFilterDefFree(objdef); obj->def = def; + virNWFilterObjDemoteFromWrite(obj); return obj; }

What is the idea behind this if()? I don't understand it. There doesn't seem to be any fields in @objdef or

+ /* Set newDef and run the trigger with a demoted lock since it may need + * to grab a read lock on this object and promote before returning. */ + virNWFilterObjPromoteToWrite(obj); obj->newDef = def; + virNWFilterObjDemoteFromWrite(obj); + /* trigger the update on VMs referencing the filter */ if (virNWFilterTriggerVMFilterRebuild() < 0) { + virNWFilterObjPromoteToWrite(obj); obj->newDef = NULL; - virNWFilterObjUnlock(obj); + /* NB: We're done, no need to Demote and End, just End */ + virNWFilterObjEndAPI(&obj); return NULL; }

+ virNWFilterObjPromoteToWrite(obj); virNWFilterDefFree(objdef); obj->def = def; obj->newDef = NULL; + virNWFilterObjDemoteFromWrite(obj); return obj; }

Michal

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 using a virObjectLockable which uses pure mutexes, use the virObjectRWLockable and primarily use RWLockRead when obtaining the object lock since RWLockRead locks can be recursively obtained (up to a limit) as long as there's a corresponding unlock.

Since all the object management is within the virnwfilterobj code, we can limit the number of Write locks on the object to very small areas of code to ensure we don't run into deadlock's with other threads and domain code that will check/use the filters (it's a very delicate balance). This limits the write locks to AssignDef and Remove processing.

This patch will introduce a new API virNWFilterObjEndAPI to unlock and deref the object.

This patch introduces two helpers to promote/demote the read/write lock.

Signed-off-by: John Ferlan <jferlan@redhat.com> --- src/conf/virnwfilterobj.c | 193 +++++++++++++++++++++++---------- src/conf/virnwfilterobj.h | 9 +- src/libvirt_private.syms | 3 +- src/nwfilter/nwfilter_driver.c | 15 +-- src/nwfilter/nwfilter_gentech_driver.c | 11 +- 5 files changed, 153 insertions(+), 78 deletions(-)

diff --git a/src/conf/virnwfilterobj.c b/src/conf/virnwfilterobj.c index 87d7e7270..cd52706ec 100644 --- a/src/conf/virnwfilterobj.c +++ b/src/conf/virnwfilterobj.c @@ -34,7 +34,7 @@ VIR_LOG_INIT("conf.virnwfilterobj");

struct _virNWFilterObj { - virMutex lock; + virObjectRWLockable parent;

bool wantRemoved;

@@ -47,27 +47,69 @@ struct _virNWFilterObjList { virNWFilterObjPtr *objs; };

+static virClassPtr virNWFilterObjClass; +static void virNWFilterObjDispose(void *opaque); + + +static int +virNWFilterObjOnceInit(void) +{ + if (!(virNWFilterObjClass = virClassNew(virClassForObjectRWLockable(), + "virNWFilterObj", + sizeof(virNWFilterObj), + virNWFilterObjDispose))) + return -1; + + return 0; +} + +VIR_ONCE_GLOBAL_INIT(virNWFilterObj) +

static virNWFilterObjPtr virNWFilterObjNew(void) { virNWFilterObjPtr obj;

- if (VIR_ALLOC(obj) < 0) + if (virNWFilterObjInitialize() < 0) return NULL;

- if (virMutexInitRecursive(&obj->lock) < 0) { - virReportError(VIR_ERR_INTERNAL_ERROR, - "%s", _("cannot initialize mutex")); - VIR_FREE(obj); + if (!(obj = virObjectRWLockableNew(virNWFilterObjClass))) return NULL; - }

- virNWFilterObjLock(obj); + virObjectRWLockWrite(obj); return obj; }

+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 lock() that happens in the 2nd level must deadlock with this. On the other hand, there's no such case in the code currently. But that doesn't stop anybody from calling PromoteWrite() without understanding its limitations.

Maybe the fact that we need recursive lock for NWFilterObj means it's not a good candidate for virObjectRWLocable? It is still a good candidate for virObject though.

Or if you want to spend extra time on this, maybe introducing virObjectRecursiveLockable may be worth it (terrible name, I know).

I dunno, worked for me. The helper is being called from a thread that has taken out a READ lock at most one time and needs to get the WRITE lock in order to change things. If something else has the READ lock that thread waits until the other thread releases the READ lock as far as I understand things. Back when I first did this I had quite a lot of debug code and I have a vague recollection of seeing output from this particular path and seeing a couple of unlocks before the WRITE was taken while running the avocado tests. I have zero interest in spending more time on this. That ship sailed. If the decision is to drop the patches, then fine. I tried. I disagree that NWFilterObj is not a candidate for RWLockable - in fact it's quite the opposite *because* of the recursive locks. Additionally, because of the recursive locks we cannot use the virObjectLockable and quite frankly I see zero benefit from going down the path of just virObject. As they say, patches welcome. Somewhere along the line, I recall trying to post patches that were essentially virObjectRecursiveLockable and got NACK'd.

...

@@ -347,26 +426,39 @@ virNWFilterObjListAssignDef(virNWFilterObjListPtr nwfilters, }

+ /* Get a READ lock and immediately promote to WRITE while we adjust + * data within. */ if ((obj = virNWFilterObjListFindByName(nwfilters, def->name))) {

objdef = obj->def; if (virNWFilterDefEqual(def, objdef)) { + virNWFilterObjPromoteToWrite(obj); virNWFilterDefFree(objdef); obj->def = def; + virNWFilterObjDemoteFromWrite(obj); return obj; }

What is the idea behind this if()? I don't understand it. There doesn't seem to be any fields in @objdef or

Or you lost your train of thought? Happens with this code. The *DefEqual ensures that the new definition is the exact same as the old, but replaces the def for whatever reason - kind of the redefine type logic. If something is different, then we're stuck going through the FilterRebuild logic. That's about the extent of what I understand. John

...

+ /* Set newDef and run the trigger with a demoted lock since it may need + * to grab a read lock on this object and promote before returning. */ + virNWFilterObjPromoteToWrite(obj); obj->newDef = def; + virNWFilterObjDemoteFromWrite(obj); + /* trigger the update on VMs referencing the filter */ if (virNWFilterTriggerVMFilterRebuild() < 0) { + virNWFilterObjPromoteToWrite(obj); obj->newDef = NULL; - virNWFilterObjUnlock(obj); + /* NB: We're done, no need to Demote and End, just End */ + virNWFilterObjEndAPI(&obj); return NULL; }

+ virNWFilterObjPromoteToWrite(obj); virNWFilterDefFree(objdef); obj->def = def; obj->newDef = NULL; + virNWFilterObjDemoteFromWrite(obj); return obj; }

Michal

[...]

...

...

...

+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 lock() that happens in the 2nd level must deadlock with this. On the other hand, there's no such case in the code currently. But that doesn't stop anybody from calling PromoteWrite() without understanding its limitations.

Maybe the fact that we need recursive lock for NWFilterObj means it's not a good candidate for virObjectRWLocable? It is still a good candidate for virObject though.

Or if you want to spend extra time on this, maybe introducing virObjectRecursiveLockable may be worth it (terrible name, I know).

I dunno, worked for me. The helper is being called from a thread that has taken out a READ lock at most one time and needs to get the WRITE lock in order to change things. If something else has the READ lock that thread waits until the other thread releases the READ lock as far as I understand things.

Yes, I can see that. It's just that since the original lock is recursive I expected things to get recursive and thus I've been thinking how would this work there, nested in 2nd, 3rd, .. level. But as noted earlier, the places where lock promoting is used are kind of safe since all the locking is done at the first level.

The reason I chose rwlocks and taking a read lock by default in the FindByUUID and FindByName (as opposed to other vir*FindBy* API's which return a write locked object) is because I know there's the potential for other code to be doing Reads and rwlocks allowed for that without the need to create any sort of recursive lockable object or any sort of API to perform "trylock"'s (all things I tried until the epiphany to use rwlocks was reached when you added them for other drivers and their list protection). In the long/short run I figured that having a common way to get the lock and then deciding to change it from Read to Write as necessary would work just fine for the purpose that was needed.

...

Back when I first did this I had quite a lot of debug code and I have a vague recollection of seeing output from this particular path and seeing a couple of unlocks before the WRITE was taken while running the avocado tests.

I have zero interest in spending more time on this. That ship sailed. If the decision is to drop the patches, then fine. I tried. I disagree that NWFilterObj is not a candidate for RWLockable - in fact it's quite the opposite *because* of the recursive locks.

Well, there's a difference between recursive locks and rwlocks. And it's exactly in what happens in recursion. With recursive locks we don't need any lock promoting and thus it's safe to do read/write after lock(). With lock promoting (esp. done in unlock()+lockWrite() manner) we get TOCTOU bugs.

If we had a real lock manager available this wouldn't be a problem ;-) [sorry just my OpenVMS roots and bias showing]. Still if you read up a bit on "dlm" you'll get an idea of what I mean. There's so many locks in the nwfilter code it's a wonder it all works. It's truly unfortunate that the wrlock mechanism is undefined for promoting a read lock to write leaving the consumer with few options. Since we can limit the "updating" of the fields in @obj and getting a write lock to very specific code paths, hopefully we can limit damage and/or deadlock type and/or TOCTOU issues

...

Additionally, because of the recursive locks we cannot use the virObjectLockable and quite frankly I see zero benefit from going down the path of just virObject. As they say, patches welcome.

Somewhere along the line, I recall trying to post patches that were essentially virObjectRecursiveLockable and got NACK'd.

Why is that? IUUC the aim here is to unify all the vir*ObjectList implementations so that we can drop code duplication. And so far what I've seen only a couple of virObject* functions are needed (virObjectRef, virObjectUnref, virObjectLock and virObjectUnlock). So if we have virObjectRecursiveLockable class then we can still use those 4 functions safely and unify the code here. If you're not interested, I can cook the patches.

Yes, reduction of duplication of vir*ObjectList is/was a goal. How to get there is where opinions start to vary - my code was essentially NACK'd, but getting to a point where someone else could try something different I figured would at least be helpful. This nwfilter code is the black sheep of the libvirt family in more ways than one. BTW: We're still not at a point where common List mgmt code could be written because the domain list mgmt varies greatly between the various hypervisor's. I started writing some patches to work through those issues, but have been side tracked by other higher priority items. BTW, see: https://www.redhat.com/archives/libvir-list/2017-May/msg01183.html for my pass at virObjectLockableRecursiveNew

...

...

...

@@ -347,26 +426,39 @@ virNWFilterObjListAssignDef(virNWFilterObjListPtr nwfilters, }

+ /* Get a READ lock and immediately promote to WRITE while we adjust + * data within. */ if ((obj = virNWFilterObjListFindByName(nwfilters, def->name))) {

objdef = obj->def; if (virNWFilterDefEqual(def, objdef)) { + virNWFilterObjPromoteToWrite(obj); virNWFilterDefFree(objdef); obj->def = def; + virNWFilterObjDemoteFromWrite(obj); return obj; }

What is the idea behind this if()? I don't understand it. There doesn't seem to be any fields in @objdef or

Or you lost your train of thought? Happens with this code. The *DefEqual ensures that the new definition is the exact same as the old, but replaces the def for whatever reason - kind of the redefine type logic. If something is different, then we're stuck going through the FilterRebuild logic.

That's about the extent of what I understand.

Yes, but the part that I'm not understanding is why we are replacing the definition in the first place. I mean, if this were some integers instead of pointers:

int x = 42;

if (struct.member == x) { struct.member = x; }

It makes exactly zero sense to me. But whatever, it's pre-existing.

Right, pre-existing is what I'm going with 0-) John

On 02/08/2018 08:13 AM, Michal Privoznik wrote:

On 02/06/2018 08:20 PM, John Ferlan wrote:

...

Implement the self locking object list for nwfilter object lists that uses two hash tables to store the nwfilter object by UUID or by Name.

As part of this alter the uuid argument to virNWFilterObjLookupByUUID to expect an already formatted uuidstr.

Alter the existing list traversal code to implement the hash table find/lookup/search functionality.

Signed-off-by: John Ferlan <jferlan@redhat.com> --- src/conf/virnwfilterobj.c | 405 ++++++++++++++++++++++++++++------------- src/conf/virnwfilterobj.h | 2 +- src/nwfilter/nwfilter_driver.c | 5 +- 3 files changed, 283 insertions(+), 129 deletions(-)

...

@@ -425,24 +483,26 @@ virNWFilterObjListAssignDef(virNWFilterObjListPtr nwfilters, return NULL; }

- - /* Get a READ lock and immediately promote to WRITE while we adjust - * data within. */ - if ((obj = virNWFilterObjListFindByName(nwfilters, def->name))) { + /* We're about to make some changes to objects on the list - so get the + * list READ lock in order to Find the object and WRITE lock the object + * since both paths would immediately promote it anyway */ + virObjectRWLockRead(nwfilters); + if ((obj = virNWFilterObjListFindByNameLocked(nwfilters, def->name))) { + virObjectRWLockWrite(obj); + virObjectRWUnlock(nwfilters);

objdef = obj->def; if (virNWFilterDefEqual(def, objdef)) { - virNWFilterObjPromoteToWrite(obj); virNWFilterDefFree(objdef); obj->def = def; virNWFilterObjDemoteFromWrite(obj); return obj; }

- /* Set newDef and run the trigger with a demoted lock since it may need - * to grab a read lock on this object and promote before returning. */ - virNWFilterObjPromoteToWrite(obj); obj->newDef = def; + + /* Demote while the trigger runs since it may need to grab a read + * lock on this object and promote before returning. */ virNWFilterObjDemoteFromWrite(obj);

/* trigger the update on VMs referencing the filter */ @@ -462,39 +522,113 @@ virNWFilterObjListAssignDef(virNWFilterObjListPtr nwfilters, return obj; }

+ /* Promote the nwfilters to add a new object */ + virObjectRWUnlock(nwfilters); + virObjectRWLockWrite(nwfilters);

How can this work? What if there's another thread waiting for the write lock (e.g. just to define an NWFilter)? The Unlock(nwfilters) wakes up the other thread, it does its job, unlocks the list waking us in turn. So we lock @nwfilters for writing and add something into the hash table - without all the checks (e.g. duplicity check) done earlier.

I dunno - works in the tests I've run (libvirt-tck and avocado). John

On 02/08/2018 08:13 AM, Michal Privoznik wrote:
> On 02/06/2018 08:20 PM, John Ferlan wrote:
>> Implement the self locking object list for nwfilter object lists
>> that uses two hash tables to store the nwfilter object by UUID or
>> by Name.
>>
>> As part of this alter the uuid argument to virNWFilterObjLookupByUUID
>> to expect an already formatted uuidstr.
>>
>> Alter the existing list traversal code to implement the hash table
>> find/lookup/search functionality.
>>
>> Signed-off-by: John Ferlan <jferlan@redhat.com>
>> ---
>>   src/conf/virnwfilterobj.c      | 405 ++++++++++++++++++++++++++++-------------
>>   src/conf/virnwfilterobj.h      |   2 +-
>>   src/nwfilter/nwfilter_driver.c |   5 +-
>>   3 files changed, 283 insertions(+), 129 deletions(-)
>
>> @@ -425,24 +483,26 @@ virNWFilterObjListAssignDef(virNWFilterObjListPtr nwfilters,
>>           return NULL;
>>       }
>>   
>> -
>> -    /* Get a READ lock and immediately promote to WRITE while we adjust
>> -     * data within. */
>> -    if ((obj = virNWFilterObjListFindByName(nwfilters, def->name))) {
>> +    /* We're about to make some changes to objects on the list - so get the
>> +     * list READ lock in order to Find the object and WRITE lock the object
>> +     * since both paths would immediately promote it anyway */
>> +    virObjectRWLockRead(nwfilters);
>> +    if ((obj = virNWFilterObjListFindByNameLocked(nwfilters, def->name))) {
>> +        virObjectRWLockWrite(obj);
>> +        virObjectRWUnlock(nwfilters);
>>   
>>           objdef = obj->def;
>>           if (virNWFilterDefEqual(def, objdef)) {
>> -            virNWFilterObjPromoteToWrite(obj);
>>               virNWFilterDefFree(objdef);
>>               obj->def = def;
>>               virNWFilterObjDemoteFromWrite(obj);
>>               return obj;
>>           }
>>   
>> -        /* Set newDef and run the trigger with a demoted lock since it may need
>> -         * to grab a read lock on this object and promote before returning. */
>> -        virNWFilterObjPromoteToWrite(obj);
>>           obj->newDef = def;
>> +
>> +        /* Demote while the trigger runs since it may need to grab a read
>> +         * lock on this object and promote before returning. */
>>           virNWFilterObjDemoteFromWrite(obj);
>>   
>>           /* trigger the update on VMs referencing the filter */
>> @@ -462,39 +522,113 @@ virNWFilterObjListAssignDef(virNWFilterObjListPtr nwfilters,
>>           return obj;
>>       }
>>   
>> +    /* Promote the nwfilters to add a new object */
>> +    virObjectRWUnlock(nwfilters);
>> +    virObjectRWLockWrite(nwfilters);
> How can this work? What if there's another thread waiting for the write
> lock (e.g. just to define an NWFilter)? The Unlock(nwfilters) wakes up
> the other thread, it does its job, unlocks the list waking us in turn.
> So we lock @nwfilters for writing and add something into the hash table
> - without all the checks (e.g. duplicity check) done earlier.

Could we keep the read lock and grab a 2nd lock as a write-lock? It 
wouldn't be a virObject call, though.

     Stefan

On 02/09/2018 01:48 AM, Michal Privoznik wrote:

On 02/08/2018 10:13 PM, Stefan Berger wrote:

...

On 02/08/2018 08:13 AM, Michal Privoznik wrote:

...

...

Implement the self locking object list for nwfilter object lists that uses two hash tables to store the nwfilter object by UUID or by Name.

As part of this alter the uuid argument to virNWFilterObjLookupByUUID to expect an already formatted uuidstr.

Alter the existing list traversal code to implement the hash table find/lookup/search functionality.

Signed-off-by: John Ferlan <jferlan@redhat.com> --- src/conf/virnwfilterobj.c | 405 ++++++++++++++++++++++++++++------------- src/conf/virnwfilterobj.h | 2 +- src/nwfilter/nwfilter_driver.c | 5 +- 3 files changed, 283 insertions(+), 129 deletions(-) @@ -425,24 +483,26 @@ virNWFilterObjListAssignDef(virNWFilterObjListPtr nwfilters, return NULL; } - - /* Get a READ lock and immediately promote to WRITE while we adjust - * data within. */ - if ((obj = virNWFilterObjListFindByName(nwfilters, def->name))) { + /* We're about to make some changes to objects on the list - so get the + * list READ lock in order to Find the object and WRITE lock the object + * since both paths would immediately promote it anyway */ + virObjectRWLockRead(nwfilters); + if ((obj = virNWFilterObjListFindByNameLocked(nwfilters, def->name))) { + virObjectRWLockWrite(obj); + virObjectRWUnlock(nwfilters); objdef = obj->def; if (virNWFilterDefEqual(def, objdef)) { - virNWFilterObjPromoteToWrite(obj); virNWFilterDefFree(objdef); obj->def = def; virNWFilterObjDemoteFromWrite(obj); return obj; } - /* Set newDef and run the trigger with a demoted lock since it may need - * to grab a read lock on this object and promote before returning. */ - virNWFilterObjPromoteToWrite(obj); obj->newDef = def; + + /* Demote while the trigger runs since it may need to grab a read + * lock on this object and promote before returning. */ virNWFilterObjDemoteFromWrite(obj); /* trigger the update on VMs referencing the filter */ @@ -462,39 +522,113 @@ virNWFilterObjListAssignDef(virNWFilterObjListPtr nwfilters, return obj; } + /* Promote the nwfilters to add a new object */ + virObjectRWUnlock(nwfilters); + virObjectRWLockWrite(nwfilters); How can this work? What if there's another thread waiting for the write lock (e.g. just to define an NWFilter)? The Unlock(nwfilters) wakes up

On 02/06/2018 08:20 PM, John Ferlan wrote: the other thread, it does its job, unlocks the list waking us in turn. So we lock @nwfilters for writing and add something into the hash table - without all the checks (e.g. duplicity check) done earlier. Could we keep the read lock and grab a 2nd lock as a write-lock? It wouldn't be a virObject call, though. That is not possible because write & read lock must exclude each other by definition.

We can grab lock A and then lock B. Lock B would either be a read/write lock locked as a write lock or would be an exclusive lock. Why would that not work? Stefan

Michal

On 02/12/2018 04:38 AM, Michal Privoznik wrote:

On 02/09/2018 12:47 PM, Stefan Berger wrote:

...

...

On 02/08/2018 10:13 PM, Stefan Berger wrote:

...

On 02/08/2018 08:13 AM, Michal Privoznik wrote:

...

...

Implement the self locking object list for nwfilter object lists that uses two hash tables to store the nwfilter object by UUID or by Name.

As part of this alter the uuid argument to virNWFilterObjLookupByUUID to expect an already formatted uuidstr.

Alter the existing list traversal code to implement the hash table find/lookup/search functionality.

Signed-off-by: John Ferlan <jferlan@redhat.com> --- src/conf/virnwfilterobj.c | 405 ++++++++++++++++++++++++++++------------- src/conf/virnwfilterobj.h | 2 +- src/nwfilter/nwfilter_driver.c | 5 +- 3 files changed, 283 insertions(+), 129 deletions(-) @@ -425,24 +483,26 @@ virNWFilterObjListAssignDef(virNWFilterObjListPtr nwfilters, return NULL; } - - /* Get a READ lock and immediately promote to WRITE while we adjust - * data within. */ - if ((obj = virNWFilterObjListFindByName(nwfilters, def->name))) { + /* We're about to make some changes to objects on the list - so get the + * list READ lock in order to Find the object and WRITE lock the object + * since both paths would immediately promote it anyway */ + virObjectRWLockRead(nwfilters); + if ((obj = virNWFilterObjListFindByNameLocked(nwfilters, def->name))) { + virObjectRWLockWrite(obj); + virObjectRWUnlock(nwfilters); objdef = obj->def; if (virNWFilterDefEqual(def, objdef)) { - virNWFilterObjPromoteToWrite(obj); virNWFilterDefFree(objdef); obj->def = def; virNWFilterObjDemoteFromWrite(obj); return obj; } - /* Set newDef and run the trigger with a demoted lock since it may need - * to grab a read lock on this object and promote before returning. */ - virNWFilterObjPromoteToWrite(obj); obj->newDef = def; + + /* Demote while the trigger runs since it may need to grab a read + * lock on this object and promote before returning. */ virNWFilterObjDemoteFromWrite(obj); /* trigger the update on VMs referencing the filter */ @@ -462,39 +522,113 @@ virNWFilterObjListAssignDef(virNWFilterObjListPtr nwfilters, return obj; } + /* Promote the nwfilters to add a new object */ + virObjectRWUnlock(nwfilters); + virObjectRWLockWrite(nwfilters); How can this work? What if there's another thread waiting for the write lock (e.g. just to define an NWFilter)? The Unlock(nwfilters) wakes up

On 02/06/2018 08:20 PM, John Ferlan wrote: the other thread, it does its job, unlocks the list waking us in turn. So we lock @nwfilters for writing and add something into the hash table - without all the checks (e.g. duplicity check) done earlier. Could we keep the read lock and grab a 2nd lock as a write-lock? It wouldn't be a virObject call, though. That is not possible because write & read lock must exclude each other by definition. We can grab lock A and then lock B. Lock B would either be a read/write lock locked as a write lock or would be an exclusive lock. Why would

On 02/09/2018 01:48 AM, Michal Privoznik wrote: that not work? Oh, I'm misunderstanding. What do you mean by locks A and B? virNWFilterObj and virNWFilterObjList locks or something else?

We could use the lock for recursive locking as we do it now. For 'promoting' to write lock we would grab a 2nd lock that's exclusive. Stefan

Michal

-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list