Re: [libvirt] [PATCH 2/6] virObject: Introduce virObjectRecursiveLockableNew

2018-02-16 Thread John Ferlan 


On 02/16/2018 04:47 AM, Michal Privoznik wrote:
> On 02/16/2018 10:08 AM, Peter Krempa wrote:
>> On Fri, Feb 16, 2018 at 09:52:53 +0100, Michal Privoznik wrote:
>>> On 02/16/2018 09:34 AM, Pavel Hrdina wrote:
 On Mon, Feb 12, 2018 at 01:16:28PM +0100, Michal Privoznik wrote:
> On 02/12/2018 01:10 PM, Peter Krempa wrote:
>> On Mon, Feb 12, 2018 at 11:52:49 +0100, Michal Privoznik wrote:
>>> Sometimes we need the lock in virObjectLockable to be recursive.
>>> Because of the nature of pthreads we don't need a special class
>>> for that - the pthread_* APIs don't distinguish between normal
>>> and recursive locks.
>>>
>>> Based-on-work-of: John Ferlan 
>>> Signed-off-by: Michal Privoznik 
>>> ---
>>>  src/libvirt_private.syms |  1 +
>>>  src/util/virobject.c | 22 +++---
>>>  src/util/virobject.h |  4 
>>>  3 files changed, 24 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
>>> index 3b14d7d15..fcf378105 100644
>>> --- a/src/libvirt_private.syms
>>> +++ b/src/libvirt_private.syms
>>
>> [...]
>>
>>> This can be viewed as rewrite of existing code, not completely new code.
>>>

 I know that NWFilter code is complex and removing recursive locks is
 not an easy task, but for the long run I think it's worth it, it will
 make the code cleaner and easier to follow.
>>>
>>> Right, that the ideal goal. But as I said it's far from happening. I
>>> think it was you who when trying to fix some issue in NWFilter drew call
>>> graph in NWFilter driver and realized how complicated it is. That's why
>>> I don't see it happening anywhere in near future. Also, if we really
>>> have multiple entry points as Dan mentioned earlier can we really fix
>>> this? I mean there are multiple locks that need to be acquired when
>>> touching a virNWFilterObj. The advantage of reentrant mutex is that we
>>> will not get a dead lock scenario if two functions fight over lock.
>>>
>>> Anyway, it's a pity that we are stuck on this patch while reworking the
>>> vir*ObjList code.
>>
>> So and why can't we keep the NWfilter code as-is until the locking is
>> sanitized first? It is working so I don't see a reason to try to rewrite
>> it to objects if it is not trivially possible.
>>

That assumes some day locks will be sanitized or the nwfilter code will
be rewritten. The chances of that happening are slim and nil AFAICT.
Perhaps the "best" one could do is keep a cache of already locked
objects to use for the lookup code rather than just using the "normal"
find object in list logic. That way the code doesn't need to have
recursive locks. Given that change in the code is feared - what chance
does making any change at being successful? At least the changes we're
discussing now allow the code to use existing mechanisms for object list
and object mgmt.

Keeping the nwfilter code as-is is an option, but to say it's working
would seem to gloss over the fact that it's using recursive locks that
can be used for write, but aren't "yet" unless someone removes the
nwfilter driver, filter update, and callback locks in the define,
undefine, and reload paths that keep any chance of an update in a single
threaded path.

> 
> Well, I find it somewhat disappointing. The patches that John and I
> proposed make things better. But because they don't make it 100% better
> they are NACKed. But I can live with having two different
> implementations for vir*ObjList if that's what we want. Or if it's
> better than having either John's or mines patches merged. I think
> otherwise though.
> 

At some point in time using virObjectLockable for managing refs, locks,
and memory reclamation was deemed making things better.

At some point in libvirt history virMutexInitRecursive was deemed to be
OK, but now it's not for the purpose of using virObject* code for nwfilters.

Eventually RWReadLocks came along which by nature allow the same thread
to hold multiple concurrent read locks as long as the same number of
matching unlocks is done.

So it seemed reasonable to me to have virNWFilterObj use an RW lock, but
in doing so the problem is we "know" it's a read lock, so in order to
update the object getting a write lock is the "normal" thing to do. That
meant promotion because it's undefined what happens if you have a read
lock and you get a write lock.

So maybe we "use" that knowledge that the define, undefine, and reload
paths are single threaded and either avoid the promotion altogether or
heavily document the NWFilterObj promotion to indicate the issue behind
doing this promotion without the additional protection so that no one
copies the logic.

Or we do nothing because things "work".

John

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

Re: [libvirt] [PATCH 2/6] virObject: Introduce virObjectRecursiveLockableNew

2018-02-16 Thread Michal Privoznik 
On 02/16/2018 10:08 AM, Peter Krempa wrote:
> On Fri, Feb 16, 2018 at 09:52:53 +0100, Michal Privoznik wrote:
>> On 02/16/2018 09:34 AM, Pavel Hrdina wrote:
>>> On Mon, Feb 12, 2018 at 01:16:28PM +0100, Michal Privoznik wrote:
 On 02/12/2018 01:10 PM, Peter Krempa wrote:
> On Mon, Feb 12, 2018 at 11:52:49 +0100, Michal Privoznik wrote:
>> Sometimes we need the lock in virObjectLockable to be recursive.
>> Because of the nature of pthreads we don't need a special class
>> for that - the pthread_* APIs don't distinguish between normal
>> and recursive locks.
>>
>> Based-on-work-of: John Ferlan 
>> Signed-off-by: Michal Privoznik 
>> ---
>>  src/libvirt_private.syms |  1 +
>>  src/util/virobject.c | 22 +++---
>>  src/util/virobject.h |  4 
>>  3 files changed, 24 insertions(+), 3 deletions(-)
>>
>> diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
>> index 3b14d7d15..fcf378105 100644
>> --- a/src/libvirt_private.syms
>> +++ b/src/libvirt_private.syms
> 
> [...]
> 
>> This can be viewed as rewrite of existing code, not completely new code.
>>
>>>
>>> I know that NWFilter code is complex and removing recursive locks is
>>> not an easy task, but for the long run I think it's worth it, it will
>>> make the code cleaner and easier to follow.
>>
>> Right, that the ideal goal. But as I said it's far from happening. I
>> think it was you who when trying to fix some issue in NWFilter drew call
>> graph in NWFilter driver and realized how complicated it is. That's why
>> I don't see it happening anywhere in near future. Also, if we really
>> have multiple entry points as Dan mentioned earlier can we really fix
>> this? I mean there are multiple locks that need to be acquired when
>> touching a virNWFilterObj. The advantage of reentrant mutex is that we
>> will not get a dead lock scenario if two functions fight over lock.
>>
>> Anyway, it's a pity that we are stuck on this patch while reworking the
>> vir*ObjList code.
> 
> So and why can't we keep the NWfilter code as-is until the locking is
> sanitized first? It is working so I don't see a reason to try to rewrite
> it to objects if it is not trivially possible.
> 

Well, I find it somewhat disappointing. The patches that John and I
proposed make things better. But because they don't make it 100% better
they are NACKed. But I can live with having two different
implementations for vir*ObjList if that's what we want. Or if it's
better than having either John's or mines patches merged. I think
otherwise though.

Michal

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

Re: [libvirt] [PATCH 2/6] virObject: Introduce virObjectRecursiveLockableNew

2018-02-16 Thread Peter Krempa 
On Fri, Feb 16, 2018 at 09:52:53 +0100, Michal Privoznik wrote:
> On 02/16/2018 09:34 AM, Pavel Hrdina wrote:
> > On Mon, Feb 12, 2018 at 01:16:28PM +0100, Michal Privoznik wrote:
> >> On 02/12/2018 01:10 PM, Peter Krempa wrote:
> >>> On Mon, Feb 12, 2018 at 11:52:49 +0100, Michal Privoznik wrote:
>  Sometimes we need the lock in virObjectLockable to be recursive.
>  Because of the nature of pthreads we don't need a special class
>  for that - the pthread_* APIs don't distinguish between normal
>  and recursive locks.
> 
>  Based-on-work-of: John Ferlan 
>  Signed-off-by: Michal Privoznik 
>  ---
>   src/libvirt_private.syms |  1 +
>   src/util/virobject.c | 22 +++---
>   src/util/virobject.h |  4 
>   3 files changed, 24 insertions(+), 3 deletions(-)
> 
>  diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
>  index 3b14d7d15..fcf378105 100644
>  --- a/src/libvirt_private.syms
>  +++ b/src/libvirt_private.syms

[...]

> This can be viewed as rewrite of existing code, not completely new code.
> 
> > 
> > I know that NWFilter code is complex and removing recursive locks is
> > not an easy task, but for the long run I think it's worth it, it will
> > make the code cleaner and easier to follow.
> 
> Right, that the ideal goal. But as I said it's far from happening. I
> think it was you who when trying to fix some issue in NWFilter drew call
> graph in NWFilter driver and realized how complicated it is. That's why
> I don't see it happening anywhere in near future. Also, if we really
> have multiple entry points as Dan mentioned earlier can we really fix
> this? I mean there are multiple locks that need to be acquired when
> touching a virNWFilterObj. The advantage of reentrant mutex is that we
> will not get a dead lock scenario if two functions fight over lock.
> 
> Anyway, it's a pity that we are stuck on this patch while reworking the
> vir*ObjList code.

So and why can't we keep the NWfilter code as-is until the locking is
sanitized first? It is working so I don't see a reason to try to rewrite
it to objects if it is not trivially possible.



signature.asc
Description: PGP signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 2/6] virObject: Introduce virObjectRecursiveLockableNew

2018-02-16 Thread Michal Privoznik 
On 02/16/2018 09:34 AM, Pavel Hrdina wrote:
> On Mon, Feb 12, 2018 at 01:16:28PM +0100, Michal Privoznik wrote:
>> On 02/12/2018 01:10 PM, Peter Krempa wrote:
>>> On Mon, Feb 12, 2018 at 11:52:49 +0100, Michal Privoznik wrote:
 Sometimes we need the lock in virObjectLockable to be recursive.
 Because of the nature of pthreads we don't need a special class
 for that - the pthread_* APIs don't distinguish between normal
 and recursive locks.

 Based-on-work-of: John Ferlan 
 Signed-off-by: Michal Privoznik 
 ---
  src/libvirt_private.syms |  1 +
  src/util/virobject.c | 22 +++---
  src/util/virobject.h |  4 
  3 files changed, 24 insertions(+), 3 deletions(-)

 diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
 index 3b14d7d15..fcf378105 100644
 --- a/src/libvirt_private.syms
 +++ b/src/libvirt_private.syms
 @@ -2417,6 +2417,7 @@ virObjectListFreeCount;
  virObjectLock;
  virObjectLockableNew;
  virObjectNew;
 +virObjectRecursiveLockableNew;
>>>
>>> I think this was NACK'd last time since we did not want to promote usage
>>> of recursive locks in the code. If we provide an object that provides
>>> recursive locking we de-facto promote this usage.
>>>
>>> As Pavel stated in his review. Ideally the NWfilter code will be
>>> converted to a less convoluted locking not requiring recursive locks
>>> prior to this so that we don't have to add recursive locking at all.
>>>
>>
>> I think that is far from happening. And I don't see any difference
>> between virObjectRecursiveLockableNew() and
>> virMutexInitRecursive() in terms of promoting something. Can you shed
>> more light where do you see the difference?
> 
> IMHO the difference is what Peter already wrote, creating new object
> that automatically uses recursive locks makes it easier to use and
> somehow promotes it, because nowadays we are rewriting a lot of code
> to use objects.
> 
> The other argument is that we should avoid recursive locks which
> includes not introducing new code that works with recursive locks.

This can be viewed as rewrite of existing code, not completely new code.

> 
> I know that NWFilter code is complex and removing recursive locks is
> not an easy task, but for the long run I think it's worth it, it will
> make the code cleaner and easier to follow.

Right, that the ideal goal. But as I said it's far from happening. I
think it was you who when trying to fix some issue in NWFilter drew call
graph in NWFilter driver and realized how complicated it is. That's why
I don't see it happening anywhere in near future. Also, if we really
have multiple entry points as Dan mentioned earlier can we really fix
this? I mean there are multiple locks that need to be acquired when
touching a virNWFilterObj. The advantage of reentrant mutex is that we
will not get a dead lock scenario if two functions fight over lock.

Anyway, it's a pity that we are stuck on this patch while reworking the
vir*ObjList code.

> 
> In conclusion, I still stand behind my NACK.

Okay, in that case I'm gonna ACK John's patches. It's very unfortunate
that because of you NACKing this patch we will have to have lock promoting.

Michal

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

Re: [libvirt] [PATCH 2/6] virObject: Introduce virObjectRecursiveLockableNew

2018-02-16 Thread Pavel Hrdina 
On Mon, Feb 12, 2018 at 01:16:28PM +0100, Michal Privoznik wrote:
> On 02/12/2018 01:10 PM, Peter Krempa wrote:
> > On Mon, Feb 12, 2018 at 11:52:49 +0100, Michal Privoznik wrote:
> >> Sometimes we need the lock in virObjectLockable to be recursive.
> >> Because of the nature of pthreads we don't need a special class
> >> for that - the pthread_* APIs don't distinguish between normal
> >> and recursive locks.
> >>
> >> Based-on-work-of: John Ferlan 
> >> Signed-off-by: Michal Privoznik 
> >> ---
> >>  src/libvirt_private.syms |  1 +
> >>  src/util/virobject.c | 22 +++---
> >>  src/util/virobject.h |  4 
> >>  3 files changed, 24 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
> >> index 3b14d7d15..fcf378105 100644
> >> --- a/src/libvirt_private.syms
> >> +++ b/src/libvirt_private.syms
> >> @@ -2417,6 +2417,7 @@ virObjectListFreeCount;
> >>  virObjectLock;
> >>  virObjectLockableNew;
> >>  virObjectNew;
> >> +virObjectRecursiveLockableNew;
> > 
> > I think this was NACK'd last time since we did not want to promote usage
> > of recursive locks in the code. If we provide an object that provides
> > recursive locking we de-facto promote this usage.
> > 
> > As Pavel stated in his review. Ideally the NWfilter code will be
> > converted to a less convoluted locking not requiring recursive locks
> > prior to this so that we don't have to add recursive locking at all.
> > 
> 
> I think that is far from happening. And I don't see any difference
> between virObjectRecursiveLockableNew() and
> virMutexInitRecursive() in terms of promoting something. Can you shed
> more light where do you see the difference?

IMHO the difference is what Peter already wrote, creating new object
that automatically uses recursive locks makes it easier to use and
somehow promotes it, because nowadays we are rewriting a lot of code
to use objects.

The other argument is that we should avoid recursive locks which
includes not introducing new code that works with recursive locks.

I know that NWFilter code is complex and removing recursive locks is
not an easy task, but for the long run I think it's worth it, it will
make the code cleaner and easier to follow.

In conclusion, I still stand behind my NACK.

Pavel

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


signature.asc
Description: PGP signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 2/6] virObject: Introduce virObjectRecursiveLockableNew

2018-02-12 Thread Michal Privoznik 
On 02/12/2018 01:10 PM, Peter Krempa wrote:
> On Mon, Feb 12, 2018 at 11:52:49 +0100, Michal Privoznik wrote:
>> Sometimes we need the lock in virObjectLockable to be recursive.
>> Because of the nature of pthreads we don't need a special class
>> for that - the pthread_* APIs don't distinguish between normal
>> and recursive locks.
>>
>> Based-on-work-of: John Ferlan 
>> Signed-off-by: Michal Privoznik 
>> ---
>>  src/libvirt_private.syms |  1 +
>>  src/util/virobject.c | 22 +++---
>>  src/util/virobject.h |  4 
>>  3 files changed, 24 insertions(+), 3 deletions(-)
>>
>> diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
>> index 3b14d7d15..fcf378105 100644
>> --- a/src/libvirt_private.syms
>> +++ b/src/libvirt_private.syms
>> @@ -2417,6 +2417,7 @@ virObjectListFreeCount;
>>  virObjectLock;
>>  virObjectLockableNew;
>>  virObjectNew;
>> +virObjectRecursiveLockableNew;
> 
> I think this was NACK'd last time since we did not want to promote usage
> of recursive locks in the code. If we provide an object that provides
> recursive locking we de-facto promote this usage.
> 
> As Pavel stated in his review. Ideally the NWfilter code will be
> converted to a less convoluted locking not requiring recursive locks
> prior to this so that we don't have to add recursive locking at all.
> 

I think that is far from happening. And I don't see any difference
between virObjectRecursiveLockableNew() and
virMutexInitRecursive() in terms of promoting something. Can you shed
more light where do you see the difference?

Michal

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

Re: [libvirt] [PATCH 2/6] virObject: Introduce virObjectRecursiveLockableNew

2018-02-12 Thread John Ferlan 


On 02/12/2018 05:52 AM, Michal Privoznik wrote:
> Sometimes we need the lock in virObjectLockable to be recursive.
> Because of the nature of pthreads we don't need a special class
> for that - the pthread_* APIs don't distinguish between normal
> and recursive locks.
> 
> Based-on-work-of: John Ferlan 
> Signed-off-by: Michal Privoznik 
> ---
>  src/libvirt_private.syms |  1 +
>  src/util/virobject.c | 22 +++---
>  src/util/virobject.h |  4 
>  3 files changed, 24 insertions(+), 3 deletions(-)
> 

Adding recursive locks to virObject* was already rejected once before:

Patch:
https://www.redhat.com/archives/libvir-list/2017-May/msg01183.html

Responses:
https://www.redhat.com/archives/libvir-list/2017-May/msg01212.html
https://www.redhat.com/archives/libvir-list/2017-May/msg01215.html

When you added RWLock's in commit '77f4593b' (afterwards) - I began
thinking - hey the NWFilter code could use those. So I essentially
ditched the effort that used trylock:

https://www.redhat.com/archives/libvir-list/2017-July/msg00673.html

in favor of one that used RWLocks:

https://www.redhat.com/archives/libvir-list/2017-October/msg00264.html

Unlike previous alterations to driver/vir*objlist code - I found that I
needed to change the vir*Obj before changing the vir*ObjList, although I
have forgotten why at this point. Eventually I also discovered why
avocado test was causing libvirtd to go defunct (as noted in the cover
of the v3). That was due to the way the test restarts libvirtd prior to
each run and an unrelated issue in nodedev w/r/t initialization, see:

https://www.redhat.com/archives/libvir-list/2017-December/msg00312.html

John

> diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
> index 3b14d7d15..fcf378105 100644
> --- a/src/libvirt_private.syms
> +++ b/src/libvirt_private.syms
> @@ -2417,6 +2417,7 @@ virObjectListFreeCount;
>  virObjectLock;
>  virObjectLockableNew;
>  virObjectNew;
> +virObjectRecursiveLockableNew;
>  virObjectRef;
>  virObjectRWLockableNew;
>  virObjectRWLockRead;
> diff --git a/src/util/virobject.c b/src/util/virobject.c
> index b2fc63aec..1d82e826b 100644
> --- a/src/util/virobject.c
> +++ b/src/util/virobject.c
> @@ -257,8 +257,9 @@ virObjectNew(virClassPtr klass)
>  }
>  
>  
> -void *
> -virObjectLockableNew(virClassPtr klass)
> +static void *
> +virObjectLockableNewInternal(virClassPtr klass,
> + bool recursive)
>  {
>  virObjectLockablePtr obj;
>  
> @@ -272,7 +273,8 @@ virObjectLockableNew(virClassPtr klass)
>  if (!(obj = virObjectNew(klass)))
>  return NULL;
>  
> -if (virMutexInit(>lock) < 0) {
> +if ((!recursive && virMutexInit(>lock) < 0) ||
> +(recursive && virMutexInitRecursive(>lock) < 0)) {
>  virReportSystemError(errno, "%s",
>   _("Unable to initialize mutex"));
>  virObjectUnref(obj);
> @@ -283,6 +285,20 @@ virObjectLockableNew(virClassPtr klass)
>  }
>  
>  
> +void *
> +virObjectLockableNew(virClassPtr klass)
> +{
> +return virObjectLockableNewInternal(klass, false);
> +}
> +
> +
> +void *
> +virObjectRecursiveLockableNew(virClassPtr klass)
> +{
> +return virObjectLockableNewInternal(klass, true);
> +}
> +
> +
>  void *
>  virObjectRWLockableNew(virClassPtr klass)
>  {
> diff --git a/src/util/virobject.h b/src/util/virobject.h
> index ac6cf22f9..367d505ae 100644
> --- a/src/util/virobject.h
> +++ b/src/util/virobject.h
> @@ -116,6 +116,10 @@ void *
>  virObjectLockableNew(virClassPtr klass)
>  ATTRIBUTE_NONNULL(1);
>  
> +void *
> +virObjectRecursiveLockableNew(virClassPtr klass)
> +ATTRIBUTE_NONNULL(1);
> +
>  void *
>  virObjectRWLockableNew(virClassPtr klass)
>  ATTRIBUTE_NONNULL(1);
> 

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

Re: [libvirt] [PATCH 2/6] virObject: Introduce virObjectRecursiveLockableNew

2018-02-12 Thread Peter Krempa 
On Mon, Feb 12, 2018 at 11:52:49 +0100, Michal Privoznik wrote:
> Sometimes we need the lock in virObjectLockable to be recursive.
> Because of the nature of pthreads we don't need a special class
> for that - the pthread_* APIs don't distinguish between normal
> and recursive locks.
> 
> Based-on-work-of: John Ferlan 
> Signed-off-by: Michal Privoznik 
> ---
>  src/libvirt_private.syms |  1 +
>  src/util/virobject.c | 22 +++---
>  src/util/virobject.h |  4 
>  3 files changed, 24 insertions(+), 3 deletions(-)
> 
> diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
> index 3b14d7d15..fcf378105 100644
> --- a/src/libvirt_private.syms
> +++ b/src/libvirt_private.syms
> @@ -2417,6 +2417,7 @@ virObjectListFreeCount;
>  virObjectLock;
>  virObjectLockableNew;
>  virObjectNew;
> +virObjectRecursiveLockableNew;

I think this was NACK'd last time since we did not want to promote usage
of recursive locks in the code. If we provide an object that provides
recursive locking we de-facto promote this usage.

As Pavel stated in his review. Ideally the NWfilter code will be
converted to a less convoluted locking not requiring recursive locks
prior to this so that we don't have to add recursive locking at all.


signature.asc
Description: PGP signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH 2/6] virObject: Introduce virObjectRecursiveLockableNew

2018-02-12 Thread Michal Privoznik 
Sometimes we need the lock in virObjectLockable to be recursive.
Because of the nature of pthreads we don't need a special class
for that - the pthread_* APIs don't distinguish between normal
and recursive locks.

Based-on-work-of: John Ferlan 
Signed-off-by: Michal Privoznik 
---
 src/libvirt_private.syms |  1 +
 src/util/virobject.c | 22 +++---
 src/util/virobject.h |  4 
 3 files changed, 24 insertions(+), 3 deletions(-)

diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
index 3b14d7d15..fcf378105 100644
--- a/src/libvirt_private.syms
+++ b/src/libvirt_private.syms
@@ -2417,6 +2417,7 @@ virObjectListFreeCount;
 virObjectLock;
 virObjectLockableNew;
 virObjectNew;
+virObjectRecursiveLockableNew;
 virObjectRef;
 virObjectRWLockableNew;
 virObjectRWLockRead;
diff --git a/src/util/virobject.c b/src/util/virobject.c
index b2fc63aec..1d82e826b 100644
--- a/src/util/virobject.c
+++ b/src/util/virobject.c
@@ -257,8 +257,9 @@ virObjectNew(virClassPtr klass)
 }
 
 
-void *
-virObjectLockableNew(virClassPtr klass)
+static void *
+virObjectLockableNewInternal(virClassPtr klass,
+ bool recursive)
 {
 virObjectLockablePtr obj;
 
@@ -272,7 +273,8 @@ virObjectLockableNew(virClassPtr klass)
 if (!(obj = virObjectNew(klass)))
 return NULL;
 
-if (virMutexInit(>lock) < 0) {
+if ((!recursive && virMutexInit(>lock) < 0) ||
+(recursive && virMutexInitRecursive(>lock) < 0)) {
 virReportSystemError(errno, "%s",
  _("Unable to initialize mutex"));
 virObjectUnref(obj);
@@ -283,6 +285,20 @@ virObjectLockableNew(virClassPtr klass)
 }
 
 
+void *
+virObjectLockableNew(virClassPtr klass)
+{
+return virObjectLockableNewInternal(klass, false);
+}
+
+
+void *
+virObjectRecursiveLockableNew(virClassPtr klass)
+{
+return virObjectLockableNewInternal(klass, true);
+}
+
+
 void *
 virObjectRWLockableNew(virClassPtr klass)
 {
diff --git a/src/util/virobject.h b/src/util/virobject.h
index ac6cf22f9..367d505ae 100644
--- a/src/util/virobject.h
+++ b/src/util/virobject.h
@@ -116,6 +116,10 @@ void *
 virObjectLockableNew(virClassPtr klass)
 ATTRIBUTE_NONNULL(1);
 
+void *
+virObjectRecursiveLockableNew(virClassPtr klass)
+ATTRIBUTE_NONNULL(1);
+
 void *
 virObjectRWLockableNew(virClassPtr klass)
 ATTRIBUTE_NONNULL(1);
-- 
2.13.6

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