On Sun, Sep 18, 2022 at 2:12 PM Nikolaus Rath <Nikolaus@xxxxxxxx> wrote: > > Hi, > > Should the FUSE kernel driver perhaps set PR_SET_IO_FLUSHER for the FUSE > userspace process daemon when a connection is opened? > This may have implications. Not sure it is good to do that unconditionally. Do you have a reproducer of deadlock? Note that PR_SET_IO_FLUSHER is set for a thread - not for a process. > If I understand correctly, this is necessary to avoid a deadlocks if the > kernel needs to reclaim memory that has to be written back through FUSE. > I think the deadlock can happen also when kernel does writeback to FUSE and then FUSE server ends up trying to do direct reclaim of memory (not just through FUSE writeback). In any case, I guess the problem is limited for writeback cache enabled. > I don't think it's possible to do this in userspace, since the process > may lack the necessary capabilities. > Doing something a bit more subtle would be to write the calling thread PF_MEMALLOC_NOXX flags in the request and let kernel set the flags of the thread reading the request, but in libfuse that is not the worker thread is it? Need to also check if PF_MEMALLOC_NOFS may also deadlock. Direct reclaim of inodes can trigger a *lot* of FUSE_FORGET requests IIRC those requests are one way, but can they block on the request queue size limit? Of course it is less common for the forget method to require large memory allocations, but we cannot assume there is no deadlock unless we make sure to prevent it. Thanks, Amir.
