Re: [fuse-devel] [PATCH 0/6] vfs: provide automatic kernel freeze / resume

[Miklos Szeredi]

On Tue, 6 Jun 2023 at 21:37, Nikolaus Rath <Nikolaus@xxxxxxxx> wrote:
>
> On Jun 06 2023, Miklos Szeredi via fuse-devel <fuse-devel@xxxxxxxxxxxxxxxxxxxxx> wrote:
> > On Sun, 14 May 2023 at 00:04, Askar Safin <safinaskar@xxxxxxxxx> wrote:
> >>
> >> Will this patch fix a long-standing fuse vs suspend bug? (
> >> https://bugzilla.kernel.org/show_bug.cgi?id=34932 )
> >
> > No.
> >
> > The solution to the fuse issue is to freeze processes that initiate
> > fuse requests *before* freezing processes that serve fuse requests.
> >
> > The problem is finding out which is which.  This can be complicated by
> > the fact that a process could be both serving requests *and*
> > initiating them (even without knowing).
> >
> > The best idea so far is to let fuse servers set a process flag
> > (PF_FREEZE_LATE) that is inherited across fork/clone.
>
> Is that the same as what userspace calls PR_SET_IO_FLUSHER? From
> prctl(2):
>
>    PR_SET_IO_FLUSHER (since Linux 5.6)
>           If a user process is involved in the block layer or filesystem I/O  path,  and
>           can allocate memory while processing I/O requests it must set arg2 to 1.  This
>           will put the process in the IO_FLUSHER state, which allows it  special  treat‐
>           ment  to make progress when allocating memory. [..]
>
>           The calling process must have the CAP_SYS_RESOURCE capability.[...]

This is the issue.   We want suspend to work without needing privileges.

>
>           Examples  of  IO_FLUSHER  applications are FUSE daemons, SCSI device emulation
>           daemons, and daemons that perform error handling like multipath path  recovery
>           applications.

This looks incorrect.  FUSE shouldn't need this because it manages
writeback in a way not to require such special treatment.

It might make sense to use the prctl(2) API for this, but honestly I
prefer pseudo fs interfaces for such knobs.

Thanks,
Miklos