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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJfpegvMNqZiNp9wWvqtgOiBHGd48C1+2ZtMt1i_gtE6v+X7fA@mail.gmail.com>
Date:   Wed, 7 Jun 2023 09:04:34 +0200
From:   Miklos Szeredi <miklos@...redi.hu>
To:     Miklos Szeredi via fuse-devel <fuse-devel@...ts.sourceforge.net>,
        Askar Safin <safinaskar@...il.com>,
        Miklos Szeredi <miklos@...redi.hu>, linux-pm@...r.kernel.org,
        Bernd Schubert <bernd.schubert@...tmail.fm>,
        linux-kernel@...r.kernel.org, Luis Chamberlain <mcgrof@...nel.org>,
        linux-fsdevel@...r.kernel.org
Subject: Re: [fuse-devel] [PATCH 0/6] vfs: provide automatic kernel freeze / resume

On Tue, 6 Jun 2023 at 21:37, Nikolaus Rath <Nikolaus@...h.org> wrote:
>
> On Jun 06 2023, Miklos Szeredi via fuse-devel <fuse-devel@...ts.sourceforge.net> wrote:
> > On Sun, 14 May 2023 at 00:04, Askar Safin <safinaskar@...il.com> 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