On Fri, 18 Oct 2024 at 03:30, Joanne Koong <joannelkoong@xxxxxxxxx> wrote: > I need to analyze the page fault path more to get a clearer picture of > what is happening, but so far this looks like a valid case for a > correctly written fuse server to run into. Yes. > For the syscalls however, is it valid/safe in general (disregarding > the writeback deadlock scenario for a minute) for fuse servers to be > invoking these syscalls in their handlers anyways? Generally no. Any kind of recursion in fuse is a landmine. E.g. CVE-2019-20794 was created to track an issue with a fuse server going unkillable on namespace shutdown. It didn't occur to the reporter that this is just a special case of a plain old recursive deadlock, because it happens to be triggered by kill. But recursion is clearly there: there's a file descriptor referring to the same fuse mount that is being served. When this fd is closed at process exit the recursion is triggered and the thing deadlocks. The fix: move the recursive part of the code to a different process. But people seem to believe that recursion is okay and the kernel should deal with that :-/ > The other places where I see a generic wait on writeback seem safe: > * splice, page_cache_pipe_buf_try_steal() (fs/splice.c): > We hit this in fuse when we try to move a page from the pipe buffer > into the page cache (fuse_try_move_page()) for the SPLICE_F_MOVE case. > This wait seems fine, since the folio that's being waited on is the > folio in the pipe buffer which is not a fuse folio. > * memory failure (mm/memory_failure.c): > Soft offlining a page and handling page memory failure - these can > be triggered asynchronously (memory_failure_work_func()), but this > should be fine for the fuse use case since the server isn't blocked on > servicing any writeback requests while memory failure handling is > waiting on writeback > * page truncation (mm/truncate.c): > Same here. These cases seem fine since the server isn't blocked on > servicing writeback requests while truncation waits on writeback Right. Thanks, Miklos
