On Wed, May 17, 2023 at 12:43:34AM -0700, Christoph Hellwig wrote: > On Wed, May 17, 2023 at 08:40:26AM +0100, Lorenzo Stoakes wrote: > > > I'm not sure what you mean by "total flexibility" here. In my opinion it is > > > also about how HW performs checksumming etc. > > > > I mean to say *_ops allow a lot of flexibility in how things are > > handled. Certainly checksumming is a great example but in theory an > > arbitrary filesystem could be doing, well, anything and always assuming > > that only userland mappings should be modifying the underlying data. > > File systems need a wait to track when a page is dirtied so that it can > be written back. Not much to do with flexbility. 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. Not least for checksumming (e.g. assume hw-reported checksum for a block == checksum derived from page cache) but, because VFS allows a great deal of flexibility in how filesystems are implemented, perhaps in other respects we haven't considered. So I just wanted to highlight (happy to be corrected if I'm wrong) that the PRIMARY problem is the dirty tracking breaking, but also strikes me that arbitrary writes to 'clean' pages in the background is one too.
