Re: [LSF/MM/BPF TOPIC] Migrating the un-migratable

[Shakeel Butt <shakeel.butt@linux.dev>]

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@mail.gmail.com/