On Wed, 16 Oct 2024 at 11:44, Jingbo Xu <jefflexu@xxxxxxxxxxxxxxxxx> wrote: > 1) a non-malicious fuse daemon wants to allocate some memory when > processing a fuse request, which in turn leads to memory reclaim and > thus waiting on the writeback of fuse dirty pages - a deadlock here. > This is reasonable and also the target scenario that this series wants > to fix. > > 2) a malicious fuse daemon refuses to process any request; or a buggy or > not well-written fuse daemon as you described, e.g. may call sync(2) > itself or access page cache backed by itself, then > 2.1) any unrelated user process attempting to initiate a sync(2) > itself, will hang there. This scenario is also unexpected and shall be > fixed. Exactly. We only care about - properly written server not deadlocking - buggy or malicious server not denying service to unrelated tasks, where unrelated means it would not otherwise be able to access the fuse mount. Typically this separation is done with a user namespace or -oallow_other. Thanks, Miklos > 2.2) any direct user of fuse filesystem (e.g. access files backed by > fuse filesystem) will hang in this case. IMHO this is expected, and the > impact is affordable as it is controlled within certain range (the > direct user of the fs). > > -- > Thanks, > Jingbo
