On Sun, 27 Apr 2014, Peter Zijlstra wrote: > On Sat, Apr 26, 2014 at 08:07:11PM +0200, Peter Zijlstra wrote: > > > > 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.. > > OK, so I've been thinking and figured I either mis-understand how the > hardware works or don't understand how Linus' patch will actually fully > fix the issue. > > So what both try_to_unmap_one() and zap_pte_range() end up doing is > clearing the PTE entry and then flushing the TLBs. > > However, that still leaves a window where there are remote TLB entries. > What if any of those remote entries cause a write (or have a dirty bit > cached) while we've already removed the PTE entry. > > This means that the remote CPU cannot update the PTE anymore (its not > there after all). > > Will the hardware fault when it does a translation and needs to update > the dirty/access bits while the PTE entry is !present? Yes - but I'm sure you know that, just not while you wrote the mail ;) But it will not fault while it still has the entry in its TLB, with dirty (and access) bits set in that entry in its TLB. The problem is with those entries, which already have dirty set in the TLB, although it's now cleared in the page table itself. I'm answering this mail because it only seems to need "Yes"; but well aware that I've not yet answered your yesterday's mail. Sorry, my yesterday had to be spent on... other stuff. I'm sleeping at present (well, not quite) and preparing a reply in the interstices of my sleep - if I don't change my mind before answering, I still think shmem needs Linus's (or my) patch. But woke with a panic attack that we have overlooked the question of how page reclaim's page_mapped() checks are serialized. Perhaps this concern will evaporate with the morning dew, perhaps it will not... Hugh -- 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
