On Thu, Jan 26, 2017 at 08:09:09AM +0900, Minchan Kim wrote: > Hello, > > On Wed, Jan 25, 2017 at 09:15:19AM -0800, Shaohua Li wrote: > > On Tue, Jan 24, 2017 at 11:32:12AM +0900, Minchan Kim wrote: > > > Hi Shaohua, > > > > > > On Mon, Jan 23, 2017 at 03:15:52PM -0800, Shaohua Li wrote: > > > > The page reclaim has an assumption writting to a page with clean pte > > > > should trigger a page fault, because there is a window between pte zero > > > > and tlb flush where a new write could come. If the new write doesn't > > > > trigger page fault, page reclaim will not notice it and think the page > > > > is clean and reclaim it. The MADV_FREE pages don't comply with the rule > > > > and the pte is just cleaned without writeprotect, so there will be no > > > > pagefault for new write. This will cause data corruption. > > > > > > It's hard to understand. > > > Could you show me exact scenario seqence you have in mind? > > Sorry for the delay, for some reason, I didn't receive the mail. > > in try_to_unmap_one: > > CPU 1: CPU2: > > 1. pteval = ptep_get_and_clear(mm, address, pte); > > 2. write to the address > > 3. tlb flush > > > > step 1 will get a clean pteval, step2 dirty it, but the unmap missed the dirty > > bit so discard the page without pageout. step2 doesn't trigger a page fault, > > I thought about that when Mel introduced deferred flush and concluded it > should be no problem from theses discussion: > > 1. https://lkml.org/lkml/2015/4/15/565 > 2. https://lkml.org/lkml/2015/4/16/136 > > So, shouldn't it make trap? > > Ccing Mel. Ah, don't know the cpu will refetch and trigger the fault. Thanks for the clarification. Thanks, Shaohua -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
