On Fri, Jun 05, 2020 at 10:31:59AM +1000, Dave Chinner wrote: > On Thu, Jun 04, 2020 at 04:50:50PM -0700, Matthew Wilcox wrote: > > > Sure, but that's not really what I was asking: why isn't this > > > !uptodate state caught before the page fault code calls > > > ->page_mkwrite? The page fault code has a reference to the page, > > > after all, and in a couple of paths it even has the page locked. > > > > If there's already a PTE present, then the page fault code doesn't > > check the uptodate bit. Here's the path I'm looking at: > > > > do_wp_page() > > -> vm_normal_page() > > -> wp_page_shared() > > -> do_page_mkwrite() > > > > I don't see anything in there that checked Uptodate. > > Yup, exactly the code I was looking at when I asked this question. > The kernel has invalidated the contents of a page, yet we still have > it mapped into userspace as containing valid contents, and we don't > check it at all when userspace generates a protection fault on the > page? Right. The iomap error path only clears PageUptodate. It doesn't go to the effort of unmapping the page from userspace, so userspace has a read-only view of a !Uptodate page. > > I think the iomap code is the only filesystem which clears PageUptodate > > on errors. > > I don't think you looked very hard. A quick scan shows at least > btrfs, f2fs, hostfs, jffs2, reiserfs, vboxfs and anything using the > iomap path will call ClearPageUptodate() on a write IO error. I'll give you btrfs and jffs2, but I don't think it's true for f2fs. The only other filesystem using the iomap bufferd IO paths today is zonefs, afaik.
