On Wed, May 17, 2023 at 08:55:27AM +0100, Lorenzo Stoakes wrote: > I'll try to take this in good faith because... yeah. I do get that, I mean > I literally created a repro for this situation and referenced in the commit > msg and comments this precise problem in my patch series that > addresses... this problem :P > > Perhaps I'm not being clear but it was simply my intent to highlight that > yes this is the primary problem but ALSO GUP writing to ostensibly 'clean' > pages 'behind the back' of a fs is _also_ a problem. Yes, it absolutely is a problem if that happens. But we can just fix it in the kernel using the: lock_page() copy data set_page_dirty_locked() unlock_page(); pattern, and we should have covere every place that did in tree. But there's no good way to verify it except for regular code audits.
