> > I think we could look at mapping_cap_account_dirty(page->mapping) while > > holding the ptelock, the mapping can't go away while we hold that lock. > > > > And afaict that's the exact differentiator between these two cases. > > Yes, that's easily done, but I wasn't sure whether it was correct to > skip on shmem or not - just because shmem doesn't participate in the > page_mkclean() protocol, doesn't imply it's free from similar bugs. > > I haven't seen a precise description of the bug we're anxious to fix: > Dave's MADV_DONTNEED should be easily fixable, that's not a concern; > Linus's first patch wrote of writing racing with cleaning, but didn't > give a concrete example. The way I understand it is that we observe the PTE dirty and set PAGE dirty before we make the PTE globally unavailable (through a TLB flush), and thereby we can mistakenly loose updates; by thinking a page is in fact clean even though we can still get updates. But I suspect you got that far.. > How about this: a process with one thread repeatedly (but not very often) > writing timestamp into a shared file mapping, but another thread munmaps > it at some point; and another process repeatedly (but not very often) > reads the timestamp file (or peeks at it through mmap); with memory > pressure forcing page reclaim. > > In the page_mkclean() shared file case, the second process might see > the timestamp move backwards: because a write from the timestamping > thread went into the pagecache after it had been written, but the > page not re-marked dirty; so when reclaimed and later read back > from disk, the older timestamp is seen. > > But I think you can remove "page_mkclean() " from that paragraph: > the same can happen with shmem written out to swap. I'm not entirely seeing how this could happen for shmem; the swap path goes through try_to_unmap_one(), which removes the PTE and does a full TLB flush. Anything after that will get a fault (which will hit either the swapcache or actual swap). The rmap walk of try_to_unmap() is the same as the one for page_mkclean(). So if we're good on the one, we're good on the other. -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
