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? 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?
Thanks much, Maxim. On Tue, Oct 17, 2017 at 11:25 PM, Richard W.M. Jones <[email protected]> wrote: > [Please keep replies on the mailing list so that others can benefit] > > On Tue, Oct 17, 2017 at 10:07:31PM +0300, Maxim Kozover wrote: > > Hi Richard, > > Unfortunately I achieved a negative result, maybe you could help, please? > . > > I'm using libguestfs-1.36.4 as a base since I changed for myself a bit > some > > detection stuff that you recently moved from C to OCaml and I can't > rewrite > > it immediately. > > > > WIth vanilla 1.36.4 just changing fuse_loop to fuse_loop_mt gives almost > > immediate crash when the filesystem is accessed. > > That's expected because plain 1.36 doesn't support multithreading, but ... > > > I've put the most recent gnulib, changed a bit bootstrap etc, put the > > patches from https://www.redhat.com/archives/libguestfs/2017-June/ > > msg00287.html and rebuilt. > > ... OK. > > > The system seems to work (with single-threaded fuse). > > Changed fuse_loop to fuse_loop_mt, rebuilt and fuse is stuck on the first > > call to appropriate fuse "system call" like mount_local_getattr in case > of > > ls. > > It is stuck at guestfs_lstatns possibly at ACQUIRE_LOCK_FOR_CURRENT_ > SCOPE, > > while being called from fuse. > > Can you get a stack trace from gdb. Use the command ‘t a a bt’ to > show stacks from all threads at the same time. > > > What do you think could be a problem? Some lock already taken? > > Also, maybe less concern for me as I use fuse read-only, is the directory > > cache guarded? > > Possibly not, I've not really looked at the fuse code w.r.t > multithreading at all. Patches welcome as usual. > > Rich. > > -- > Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~ > rjones > Read my programming and virtualization blog: http://rwmj.wordpress.com > libguestfs lets you edit virtual machines. Supports shell scripting, > bindings from many languages. http://libguestfs.org >
_______________________________________________ Libguestfs mailing list [email protected] https://www.redhat.com/mailman/listinfo/libguestfs
