On 2/25/22 10:30 AM, Daniel P. Berrangé wrote:
The virNWFilterLockIface method is only called from one place,
the learnIPAddressThread method.
nwfilter_gentech_driver.c:virNWFilterDoInstantiate() and
_virNWFilterTeardownFilter() also call virNWFilterLockIface.
And there is this call chain from learnIPAddressThread() that ends up at
one or the other of those:
learnIPAddressThread()
virNWFilterInstantiateFilterLate()
virNWFilterInstantiateFilterUpdate()
virNWFilterDoInstantiate() <----
_virNWFilterTeardownFilter() <----
But of course just prior to calling virNWFilterINstantiateFilterLate(),
learnIPAddressThread() calls:
virNWFilterUnlockIface(req->binding->portdevname);
which matches the previous virNWFilterLockIface(), so there shouldn't be
a problem for the learnIPAddressThread at least.
I'm not sure about the threads of other calls to
virNWFilterDoInstantiate/TeardownFilter though, haven't tried to
decipher them yet.
This is the entry point for
the learning thread on the interface in question. As such
there is never any recursive locking on this mutex from the
same thread. This appears to have been the case since the
code was first introduced. Thus a plain mutex is sufficient.
Signed-off-by: Daniel P. Berrangé <berrange@xxxxxxxxxx>
---
src/nwfilter/nwfilter_learnipaddr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/nwfilter/nwfilter_learnipaddr.c b/src/nwfilter/nwfilter_learnipaddr.c
index fb552bd1e6..4840b0539f 100644
--- a/src/nwfilter/nwfilter_learnipaddr.c
+++ b/src/nwfilter/nwfilter_learnipaddr.c
@@ -151,7 +151,7 @@ virNWFilterLockIface(const char *ifname)
if (!ifaceLock) {
ifaceLock = g_new0(virNWFilterIfaceLock, 1);
- if (virMutexInitRecursive(&ifaceLock->lock) < 0) {
+ if (virMutexInit(&ifaceLock->lock) < 0) {
virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
_("mutex initialization failed"));
g_free(ifaceLock);
