[Libguestfs] a question about multithreading with libguestfs

[Maxim Kozover]

Hi Richard!
Finally it seems it works after removing ACQUIRE_LOCK_FOR_CURRENT_SCOPE in
guestfs_mount_local_run and throwing away all directory cache code.
Although I didn't try to mix fuse libguestfs client with other clients, I
think guestfs_mount_local_run shouldn't take that specific lock as the
function won't exit until umount and will sit in the loop. I think it does
nothing libguestfs-related, only fuse loop activation.
What I don't understand is how that lock in guestfs_mount_local_run didn't
make problems with single threaded fuse_loop.
I'll try to run it a bit more to see if any problems are seen.
If everything is OK (hope not a false success as directory lists are slower
and race condition maybe less likely), then it should be worth to see why
directory cache made problems, maybe guard it with the same lock or
different one?
What do you think, Richard?

Many thanks for your prompt help,

Maxim.

On Wed, Oct 18, 2017 at 1:39 AM, Richard W.M. Jones <rjones at redhat.com>
wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libguestfs/attachments/20171018/8b103827/attachment.htm>