[libvirt] [PATCH 2/2] virSecurityManagerMetadataLock: Skip over duplicate paths

Daniel P. Berrangé berrange at redhat.com
Thu Jul 18 09:28:57 UTC 2019


On Thu, Jul 18, 2019 at 11:14:49AM +0200, Michal Privoznik wrote:
> If there are two paths on the list that are the same we need to
> lock it only once. Because when we try to lock it the second time
> then open() fails. And if it didn't, locking it the second time
> would fail for sure. After all, it is sufficient to lock all
> paths just once satisfy the caller.
> 
> Reported-by: Daniel Henrique Barboza <danielhb413 at gmail.com>
> Signed-off-by: Michal Privoznik <mprivozn at redhat.com>
> ---
>  src/security/security_manager.c | 23 +++++++++++++++++++++--
>  1 file changed, 21 insertions(+), 2 deletions(-)

Reviewed-by: Daniel P. Berrangé <berrange at redhat.com>


> 
> diff --git a/src/security/security_manager.c b/src/security/security_manager.c
> index ade2c96141..7c905f0785 100644
> --- a/src/security/security_manager.c
> +++ b/src/security/security_manager.c
> @@ -1294,16 +1294,35 @@ virSecurityManagerMetadataLock(virSecurityManagerPtr mgr ATTRIBUTE_UNUSED,
>       * paths A B and there's another that is trying to lock them
>       * in reversed order a deadlock might occur.  But if we sort
>       * the paths alphabetically then both processes will try lock
> -     * paths in the same order and thus no deadlock can occur. */
> +     * paths in the same order and thus no deadlock can occur.
> +     * Lastly, it makes searching for duplicate paths below
> +     * simpler. */
>      qsort(paths, npaths, sizeof(*paths), cmpstringp);
>  
>      for (i = 0; i < npaths; i++) {
>          const char *p = paths[i];
>          struct stat sb;
> +        size_t j;
>          int retries = 10 * 1000;
>          int fd;
>  
> -        if (!p || stat(p, &sb) < 0)
> +        if (!p)
> +            continue;
> +
> +        /* If there's a duplicate path on the list, skip it over.
> +         * Not only we would fail open()-ing it the second time,
> +         * we would deadlock with ourselves trying to lock it the
> +         * second time. After all, we've locked it when iterating
> +         * over it the first time. */

Presumably this deals with the problem at cold boot. Is it possible
to hit the same problem when we have cold plugged one device and
then later try to hotplug another device using the same resource,
or do the SRIOV assignment grouping requirements make the hotplug
impossible ?


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|




More information about the libvir-list mailing list