On Tue, 4 Jun 2024 at 03:57, Jingbo Xu <jefflexu@xxxxxxxxxxxxxxxxx> wrote: > IIUC, there are two sources that may cause deadlock: > 1) the fuse server needs memory allocation when processing FUSE_WRITE > requests, which in turn triggers direct memory reclaim, and FUSE > writeback then - deadlock here Yep, see the folio_wait_writeback() call deep in the guts of direct reclaim, which sleeps until the PG_writeback flag is cleared. If that happens to be triggered by the writeback in question, then that's a deadlock. > 2) a process that trigfgers direct memory reclaim or calls sync(2) may > hang there forever, if the fuse server is buggyly or malicious and thus > hang there when processing FUSE_WRITE requests Ah, yes, sync(2) is also an interesting case. We don't want unpriv fuse servers to be able to block sync(2), which means that sync(2) won't actually guarantee a synchronization of fuse's dirty pages. I don't think there's even a theoretical solution to that, but apparently nobody cares... Thanks, Mikos > > Thus the temp page design was introduced to avoid the above potential > issues. > > I think case 1 may be fixed (if any), but I don't know how case 2 can be > avoided as any one could run a fuse server in unprivileged mode. Or if > case 2 really matters? Please correct me if I miss something. > > -- > Thanks, > Jingbo
