On Wed, Oct 18, 2017 at 01:33:49AM +0300, Maxim Kozover wrote:
Hi Richard!
Maybe the function guestfs_mount_local_run shouldn't
ACQUIRE_LOCK_FOR_CURRENT_SCOPE as it doesn't talk with the daemon and sits
in the loop? What do you think?
The lock is needed for any access to the guestfs_h structure, so I'm
pretty sure that is not safe.
If I remove it from guestfs_mount_local_run (in lib/action-1.c,
don't know
how to properly remove it from ml generator), fuse_loop_mt works, but I
still don't understand how it worked with fuse_loop (single threaded) when
guestfs_mount_local_run did ACQUIRE_LOCK_FOR_CURRENT_SCOPE.
Unfortunately multiple ls -lR to the same directory tree lead to crash
while it seems multiple ls -lR to different directory trees (if not
repeated for a while) don't lead to crash, so I suspect directory cache in
fuse without guard.
Is there a quick way to disable the directory cache in fuse so I can see if
it is directory cache that leads to crash or we have to look at other parts?
You could try removing the directory cache altogether from the FUSE
code (it may run much more slowly).
Rich.
--
Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
Read my programming and virtualization blog:
http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html