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
