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... I think it's a sane but unusual thing to do. App has a thread writing to random places in a mapped file, and another calling munmap() or mprotect() to trap writes to some parts of the file in order to track what parts the first thread is dirtying. Second thread's SIGSEGV handler reinstates those mappings. First thread doesn't know about any of this, it just writes and the only side effect is timing. Or should be. Think garbage collection, change tracking, tracing, and debugging. -- Jamie -- 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
