Re: [Libguestfs] a question about multithreading with libguestfs
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 <rjones(a)redhat.com>
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
Attachments:
- attachment.html (text/html — 4.3 KB)