On Mon, Oct 01, 2018 at 04:11:27PM +1000, Dave Chinner wrote: > This reminds me so much of Linux mmap() in the mid-2000s - mmap() > worked for ext3 without being aware of page faults, And "worked" still is a bit of a stretch, as soon as you'd get ENOSPC it would still blow up badly. Which probably makes it an even better analogy to the current case. > RDMA does not call ->page_mkwrite on clean file backed pages before it > writes to them and calls set_page_dirty(), and hence RDMA to file > backed pages is completely unreliable. I'm not sure this can be > solved without having page fault capable RDMA hardware.... We can always software prefault at gup time. And also remember that while RDMA might be the case at least some people care about here it really isn't different from any of the other gup + I/O cases, including doing direct I/O to a mmap area. The only difference in the various cases is how long the area should be pinned down - some users like RDMA want a long term mapping, while others like direct I/O just need a short transient one. > We could address these use-after-free situations via forcing RDMA to > use file layout leases and revoke the lease when we need to modify > the backing store on leased files. However, this doesn't solve the > need for filesystems to receive write fault notifications via > ->page_mkwrite. Exactly. We need three things here: - notification to the filesystem that a page is (possibly) beeing written to - a way to to block fs operations while the pages are pinned - a way to distinguish between short and long term mappings, and only allow long terms mappings if they can be broken using something like leases I'm also pretty sure we already explained this a long time ago when the issue came up last year, so I'm not sure why this is even still contentious.
