On Fri, 2009-04-24 at 08:59 -0400, Chris Mason wrote: > On Fri, 2009-04-24 at 09:33 +0200, Miklos Szeredi wrote: > > On Fri, 24 Apr 2009, Miklos Szeredi wrote: > > > Hmm, I guess this is a bit nasty: the VM promises filesystems that > > > ->page_mkwrite() will be called when the page is dirtied through a > > > mapping, _almost_ all of the time. Except when munmap happens to race > > > with clear_page_dirty_for_io(). > > > > > > I don't have any ideas how this could be fixed, CC-ing linux-mm... > > > > On second thought, we could possibly just ignore the dirty bit in that > > case. Trying to write to a mapping _during_ munmap() will have pretty > > undefined results, I don't think any sane application out there should > > rely on the results of this. > > > > But how knows, the world is a weird place... > > It does happen in practice, btrfs has fallback code that triggers the > page_mkwrite when it finds a dirty page that wasn't dirtied with help > from the FS. > > I'd love to get rid of the fallback ;) So is there any reason why we shouldn't put calls to page_mkwrite in zap_pte_range? The only alternative I can think of would be to unmap the page when the filesystem starts to write it out in order to force another page fault if the user application writes more data into that page. Cheers Trond -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
