On Thu, Feb 24, 2022 at 12:48:42PM +1100, Dave Chinner wrote: > > Fair enough; on the other hand, we could also view this as making ext4 > > more robust against buggy code in other subsystems, and while other > > file systems may be losing user data if they are actually trying to do > > remote memory access to file-backed memory, apparently other file > > systems aren't noticing and so they're not crashing. > > Oh, we've noticed them, no question about that. We've got bug > reports going back years for systems being crashed, triggering BUGs > and/or corrupting data on both XFS and ext4 filesystems due to users > trying to run RDMA applications with file backed pages. Is this issue causing XFS to crash? I didn't know that. I tried the Syzbot reproducer with XFS mounted, and it didn't trigger any crashes. I'm sure data was getting corrupted, but I figured I should bring ext4 to the XFS level of "at least we're not reliably killing the kernel". On ext4, an unprivileged process can use process_vm_writev(2) to crash the system. I don't know how quickly we can get a fix into mm/gup.c, but if some other kernel path tries calling set_page_dirty() on a file-backed page without first asking permission from the file system, it seems to be nice if the file system doesn't BUG() --- as near as I can tell, xfs isn't crashing in this case, but ext4 is. - Ted
