Force unmount of fuse severes the connection between FUSE driver and its
userspace counterpart. However, open file handles will prevent the
superblock from being reclaimed. An attempt to remount the filesystem at
the same endpoint will try re-using the superblock, if still present.
Since the superblock re-use path doesn't go through the fs-specific
superblock setup code, its state in FUSE case is already disfunctional,
and that will prevent the mount from succeeding.
The patchset adds a possibility to mark the superblock  "defunc", which
will prevent its re-use by the subsequent mounts, and uses the
functionality in FUSE driver.


Daniil Lunev (2):
  fs/super: Add a flag to mark super block defunc
  FUSE: Mark super block defunc on force unmount

 fs/fuse/inode.c    | 11 +++++++++--
 fs/super.c         |  4 ++--
 include/linux/fs.h |  1 +
 3 files changed, 12 insertions(+), 4 deletions(-)

-- 
2.31.0

On Wed, 11 May 2022 at 03:31, Daniil Lunev <dlunev@chromium.org> wrote:
>
> Force unmount of fuse severes the connection between FUSE driver and its
> userspace counterpart.

Why is forced umount being used in the first place?

Thanks,
Miklos

On Wed, May 11, 2022 at 5:07 PM Miklos Szeredi <miklos@szeredi.hu> wrote:
>
> On Wed, 11 May 2022 at 03:31, Daniil Lunev <dlunev@chromium.org> wrote:
> >
> > Force unmount of fuse severes the connection between FUSE driver and its
> > userspace counterpart.
>
> Why is forced umount being used in the first place?

To correctly suspend-resume. We have been using this force unmount historically
to circumvent the suspend-resume issues which periodically occur with fuse.
We observe FUSE rejecting to remount the device because of the issue this
patchset attempts to address after the resume if there are still open
file handles
holding old super blocks. I am not sure if fuse's interaction with suspend is
something that has been resolved systematically (we are also trying to
figure that
out). Regardless of that, doing force unmount of a mount point is a legitimate
operation, and with FUSE it may leave the system in a state that is returning
errors for other legitimate operations.

Thanks,
Daniil

On Wed, 11 May 2022 at 09:36, Daniil Lunev <dlunev@chromium.org> wrote:
>
> On Wed, May 11, 2022 at 5:07 PM Miklos Szeredi <miklos@szeredi.hu> wrote:
> >
> > On Wed, 11 May 2022 at 03:31, Daniil Lunev <dlunev@chromium.org> wrote:
> > >
> > > Force unmount of fuse severes the connection between FUSE driver and its
> > > userspace counterpart.
> >
> > Why is forced umount being used in the first place?
>
> To correctly suspend-resume. We have been using this force unmount historically
> to circumvent the suspend-resume issues which periodically occur with fuse.
> We observe FUSE rejecting to remount the device because of the issue this
> patchset attempts to address after the resume if there are still open
> file handles
> holding old super blocks. I am not sure if fuse's interaction with suspend is
> something that has been resolved systematically (we are also trying to
> figure that
> out).

No progress has been made in the past decade with regard to suspend.
I mainly put that down to lack of interest.

>  Regardless of that, doing force unmount of a mount point is a legitimate
> operation, and with FUSE it may leave the system in a state that is returning
> errors for other legitimate operations.

It is a legitimate operation, but one that is not guaranteed to leave
the system in a clean state.

Thanks,
Miklos

> No progress has been made in the past decade with regard to suspend.
> I mainly put that down to lack of interest.
>
That is unfortunate.

> It is a legitimate operation, but one that is not guaranteed to leave
> the system in a clean state.
Sure, I don't think I can argue about it. The current behaviour is a problem,
however, since there is no other way to ensure the system can suspend
reliably but force unmount - we try normal unmount first and proceed with
force if that fails. Do you think that the approach proposed in this patchset
is a reasonable path to mitigate the issue?

Thanks,
Daniil

On Wed, 11 May 2022 at 11:37, Daniil Lunev <dlunev@chromium.org> wrote:
>
> > No progress has been made in the past decade with regard to suspend.
> > I mainly put that down to lack of interest.
> >
> That is unfortunate.
>
> > It is a legitimate operation, but one that is not guaranteed to leave
> > the system in a clean state.
> Sure, I don't think I can argue about it. The current behaviour is a problem,
> however, since there is no other way to ensure the system can suspend
> reliably but force unmount - we try normal unmount first and proceed with
> force if that fails. Do you think that the approach proposed in this patchset
> is a reasonable path to mitigate the issue?

At a glance it's a gross hack.   I can think of more than one way in
which this could be achieved without adding a new field to struct
super_block.

But...  what I'd really prefer is if the underlying issue of fuse vs.
suspend was properly addressed instead of adding band-aids.  And that
takes lots more resources, for sure, and the result is not guaranteed.
But you could at least give it a try.

Thanks,
Miklos

> At a glance it's a gross hack.   I can think of more than one way in
> which this could be achieved without adding a new field to struct
> super_block.
Can you advise what would be a better way to achieve that?

> But...  what I'd really prefer is if the underlying issue of fuse vs.
> suspend was properly addressed instead of adding band-aids.  And that
> takes lots more resources, for sure, and the result is not guaranteed.
> But you could at least give it a try.
We do have a limited success with userspace level sequencing of processes,
but on the kernel level - it is all quite untrivial, as you mentioned.
I did some
research, and what I found pretty much a 9 years old thread which went
nowhere at the end [1]. We would also prefer if suspend just worked (and
we have a person looking into what is actually breaking with suspend), but
there is an unbounded amount of time for how long the investigation and
search for a solution may be ongoing given the complexity of the problem,
and in the meantime there is no way to work around the problem.

Thanks,
Daniil

[1] https://linux-kernel.vger.kernel.narkive.com/UeBWfN1V/patch-fuse-make-fuse-daemon-frozen-along-with-kernel-threads

On Wed, 11 May 2022 at 13:19, Daniil Lunev <dlunev@chromium.org> wrote:
>
> > At a glance it's a gross hack.   I can think of more than one way in
> > which this could be achieved without adding a new field to struct
> > super_block.
> Can you advise what would be a better way to achieve that?

I think it would be easiest to remove the super block from the
type->fs_supers list.

Thanks,
Miklos

> I think it would be easiest to remove the super block from the
> type->fs_supers list.
I will try tomorrow and upload an updated patchset.
Thanks,
Daniil.

On 5/11/22 13:19, Daniil Lunev wrote:
>> At a glance it's a gross hack.   I can think of more than one way in
>> which this could be achieved without adding a new field to struct
>> super_block.
> Can you advise what would be a better way to achieve that?
> 
>> But...  what I'd really prefer is if the underlying issue of fuse vs.
>> suspend was properly addressed instead of adding band-aids.  And that
>> takes lots more resources, for sure, and the result is not guaranteed.
>> But you could at least give it a try.
> We do have a limited success with userspace level sequencing of processes,
> but on the kernel level - it is all quite untrivial, as you mentioned.
> I did some
> research, and what I found pretty much a 9 years old thread which went
> nowhere at the end [1]. We would also prefer if suspend just worked (and
> we have a person looking into what is actually breaking with suspend), but
> there is an unbounded amount of time for how long the investigation and
> search for a solution may be ongoing given the complexity of the problem,
> and in the meantime there is no way to work around the problem.
> 
> Thanks,
> Daniil
> 
> [1] https://linux-kernel.vger.kernel.narkive.com/UeBWfN1V/patch-fuse-make-fuse-daemon-frozen-along-with-kernel-threads

So that sounds like anything that is waiting for a response cannot be 
frozen? Assuming there is an outstanding NFS request and the NFS server 
is down, suspend would not work until the NFS server comes back?

Thanks,
Bernd