[glib] gio: drop obsoleted lock causing deadlocks on FreeBSD

[Allison Ryan Lortie <desrt src gnome org>]

commit 42b160b19f18ccb86fecac4553242ebd7ee8b78b
Author: Steven Chamberlain <steven pyro eu org>
Date:   Tue Dec 22 09:28:36 2015 +0100

    gio: drop obsoleted lock causing deadlocks on FreeBSD
    
    I think it is a recursion from the GUnixMountMonitor constructor, to a
    GLocalFileMonitor on /etc/fstab, and into GUnixMountMonitor again, now
    with a mutex already held, so it deadlocks.
    https://bugzilla.gnome.org/page.cgi?id=traceparser/trace.html&trace_id=235354
    
    That mutex in glocalfile.c:g_local_file_find_enclosing_mount() doesn't
    seem necessary any more IMHO.  Inside it, only 'mount' is modified, but
    that's just a stack variable local to this function.  When
    klass->get_mount_for_mount_path is called, it's given one const
    parameter and the other is unused, so they're unchanged. 'klass'
    doesn't seem it could be modified either inside that function.
    
    It doesn't recurse infinitely, but seems to work correctly and pass the
    testsuite after this change.
    
    The FreeBSD project already applied my patch in their ports tree, and
    their users seem happy with it.
    
    See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712848#64
    and https://bugzilla.gnome.org/show_bug.cgi?id=753378

 gio/gunionvolumemonitor.c |    6 +-----
 1 files changed, 1 insertions(+), 5 deletions(-)
---
diff --git a/gio/gunionvolumemonitor.c b/gio/gunionvolumemonitor.c
index 4c3049b..6af2664 100644
--- a/gio/gunionvolumemonitor.c
+++ b/gio/gunionvolumemonitor.c
@@ -591,11 +591,7 @@ _g_mount_get_for_mount_path (const gchar  *mount_path,
   mount = NULL;
 
   if (klass->get_mount_for_mount_path)
-    {
-      g_rec_mutex_lock (&the_volume_monitor_mutex);
-      mount = klass->get_mount_for_mount_path (mount_path, cancellable);
-      g_rec_mutex_unlock (&the_volume_monitor_mutex);
-    }
+    mount = klass->get_mount_for_mount_path (mount_path, cancellable);
 
   /* TODO: How do we know this succeeded? Keep in mind that the native
    *       volume monitor may fail (e.g. not being able to connect to