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.[...] Examples of IO_FLUSHER applications are FUSE daemons, SCSI device emulation daemons, and daemons that perform error handling like multipath path recovery applications. To me this sounds like it captures the relevant information (process is involved in filesystem I/O) rather than just a preferred behavior (flush late) and may thus be a better choice... Best, -Nikolaus
