Re: [fuse-devel] fuse_unmount()

[Mike S. <ma...@gm...>]

On Wed, Oct 12, 2011 at 4:40 AM, Max Khon <fj...@sa...> wrote:
> Hello!
>
> When I set up fuse mount using the following code:
>
> static int
> my_main(int argc, char *argv[], struct my_context *ctx)
> {
>        struct fuse *fuse;
>        char *mountpoint;
>        int multithreaded;
>        int res;
>
>        fuse = fuse_setup(argc, argv, &my_ops, sizeof(my_ops), &mountpoint,
> &multithreaded, ctx);
>        if (fuse == NULL)
>                return 1;
>        ctx->fuse = fuse;
>        ctx->fuse_chan = fuse_session_next_chan(fuse_get_session(ctx->fuse),
> NULL);
>
>        if (multithreaded)
>                res = fuse_loop_mt(fuse);
>        else
>                res = fuse_loop(fuse);
>
>        fuse_teardown(fuse, mountpoint);
>        if (res == -1)
>                return 1;
>
>        return 0;
> }
>
> ..and then do in-app (from the FUSE FS process) unmount by calling
>
> fuse_unmount(mountpoint, ctx->fuse_chan);

Are you calling this from a fuse callback function? Or do you spawn
off a separate thread somewhere to call fuse_unmount()? I'm not too
familiar with fuse internals, but I suspect calling unmount from
within a fuse callback would be a bad idea.

In my own program that uses fuse I tried to do an in-app unmount from
another thread. I was able to get it working by doing:

/* This ends up setting the 'exited' flag that the fuse loop looks for */
fuse_exit(fuse handle);

/* The open call should fail - it just causes a file-system event to
get the fuse loop to
  drop out of the read() system call so it can check the exited flag */
open(mountpoint);

The problem I had with this is that it didn't seem to close down
things on the kernel side correctly and ended up leaking memory
everytime the program ran. However, this was fixed here:
https://github.com/torvalds/linux/commit/5dfcc87fd79dfb96ed155b524337dbd0da4f5993

I've just moved my program over to do system(fusermount -u ...)
instead since it seems to be the expected way to shutdown the
file-system and prevented the memory leak even without that kernel
patch.

Hope this helps!
-Mike