Re: git: 10037d0978f8 - main - fusefs: Implement support for the auto_unmount option kernel-side

On Sun, Jan 25, 2026 at 10:39 PM Konstantin Belousov
<kostikbel@gmail.com> wrote:
>
> > diff --git a/sys/fs/fuse/fuse_device.c b/sys/fs/fuse/fuse_device.c
> > index 41387de3ce71..2c1e19953dfd 100644
> > --- a/sys/fs/fuse/fuse_device.c
> > +++ b/sys/fs/fuse/fuse_device.c
> > @@ -65,7 +65,6 @@
> >  #include <sys/module.h>
> >  #include <sys/systm.h>
> >  #include <sys/errno.h>
> > -#include <sys/param.h>
> >  #include <sys/kernel.h>
> >  #include <sys/conf.h>
> >  #include <sys/uio.h>
> > @@ -177,6 +176,11 @@ fdata_dtor(void *arg)
> >       fuse_lck_mtx_unlock(fdata->ms_mtx);
> >       FUSE_UNLOCK();
> >
> > +     if (fdata->mp && fdata->dataflags & FSESS_AUTO_UNMOUNT) {
>         if (fdata->mp != NULL && (fdata->dataflags & FSESS_AUTO_UNMOUNT) != 0) {
>
> > +             vfs_ref(fdata->mp);
> Don't you need to take the reference when the fdata is created and mp member
> is initialized, and not here?
>
> What guarantees that the mp is still ours?
> In fact, I think that you should use vfs_busy() and not vfs_ref(),
> since what prevents mp from being unmounted under us?
>
> > +             dounmount(fdata->mp, MNT_FORCE, curthread);
> > +     }
> > +

I have to admit that I had no idea what I'm doing when writing this code.
I first tried VOP_UNMOUNT, then something else, then started grepping
the source to figure how other parts of the system perform this task and
ended up with this. It worked for me for a simple test, so I put it on
the review
hoping that more knowledgeable people would catch if there is
something wrong. My bad that I didn't put you on the review too.

Anyways, to properly answer your question I'd need a pointer to a good
read on vfs_* stuff. CCing Alan as a reviewer of that code.