On Thu, Jan 30, 2025 at 09:48:42PM +0000, Matthew Wilcox wrote: > On Wed, Jan 29, 2025 at 05:10:03PM +0100, David Hildenbrand wrote: > > As one example, in context of FUSE we recently discovered that folios that > > are under writeback cannot be migrated, and user space in control of when > > writeback will end. Something similar can happen ->readahead() where user > > space is in charge of supplying page content. Networking filesystems in > > general seem to be prone to this as well. > > You're not wrong. The question is whether we're willing to put the > asterisk on "In the presence of a misbehaving server (network or fuse), > our usual guarantees do not apply". I'm not sure it's a soluble > problem, though. Normally writeback (or, as you observed, readahead) > completes just fine and we don't need to use non-movable pages for them. > > But if someone trips over the network cable, anything in flight becomes > unmovable until someone plugs it back in. We've given the DMA address > of the memory to a network adapter, and that's generally a non-revokable > step (maybe the iommu could save us, but at what cost?) > My position is more aligned with Willy's. We definitely should discuss if we can solve the general problem of (im)movability due to writeback or readahead but I think targeting precise problem will be more fruitful. Untrusted fuse server deliberatly causing immovable memory is a real problem as anyone can run fuse server and mount fuse without any permissions. At least to me a misbehaving but trusted server is less of an (practical) issue. (Please correct me if I miss something like this is also a real issue in multi-tenancy world). Joanne has some ideas [1] on fuse specific solution but having a discussion on general solution would be beneficial as well. [1] https://lore.kernel.org/all/CAJnrk1ZCgff6ZWmqKzBXFq5uAEbms46OexA1axWS5v-PCZFqJg@xxxxxxxxxxxxxx/
