https://bugzilla.kernel.org/show_bug.cgi?id=201631 --- Comment #50 from Aneesh Kumar KV (aneesh.kumar@xxxxxxxxxxxxx) --- (In reply to Jan Kara from comment #47) > OK, so it seems to be more and more clear that PPC indeed has some race in > page table updates. What I can see in the latest report is: > > Clean page (index 92, ino 681741, i_size 828368, flags 7fff0000002016, > mapcount 1) with dirty PTE (pte_val c0000005f7fae186) on unmap! Vma flags > fb, pgoff 0, file ino 681741 > ... > page 92: b_state 21, b_blocknr 2801084, b_mapped 1452389112002, b_mapped2 0, > b_cleaned 1452396217779, now 1452400395514 > > So "Vma flags fb" shows its a normal shared, writeable file mapping. Page is > somewhere in the middle of the file (file size is 828368, page is at offset > 376832). The page has been writeably mapped 11ms ago (you are using ext2 > filesystem which was confusing my previous debug attempts so only this one > has shown proper times) and written back 4ms ago (which should have > writeprotected the pte) but we still have writeable pte now on which the > assertion hits. So either page_mkclean() failed to clear the PTE or someone > created new writeable PTE without telling ext4. > > I'll attach a new version of debug patch to distinguish these two cases. The fact that we did try to write out the page at (bh_cleaned 1452396217779)implies we should have cleared the _PAGE_WRITE bit right (clear_page_dirty_for_io())? So we should either find that bit cleared in pte (if we missed a related tlb flush and tlb still has that pte with _PAGE_WRITE) or we find that set. In this case, we find _PAGE_WRITE set in the pte during zap. Does that imply we did call finish_fault()? which should have ideally resulted in we calling page_mkwrite(). I am still not clear what could be a possible race that can result in this? -aneesh -- You are receiving this mail because: You are watching the assignee of the bug.
