Re: [PATCH] mm: Prevent racy access to tlb_flush_pending

[Mel Gorman <mgorman@suse.de>]

On Mon, Jul 24, 2017 at 05:27:47PM -0700, Nadav Amit wrote:
> > Do we still need the barrier()s or is it OK to let the atomic op do
> > that for us (with a suitable code comment).
> 
> I will submit v2. However, I really don???t understand the comment on
> mm_tlb_flush_pending():
> 
> /*              
>  * Memory barriers to keep this state in sync are graciously provided by
>  * the page table locks, outside of which no page table modifications happen.
>  * The barriers below prevent the compiler from re-ordering the instructions
>  * around the memory barriers that are already present in the code.
>  */
> 
> But IIUC migrate_misplaced_transhuge_page() does not call
> mm_tlb_flush_pending() while the ptl is taken.
> 
> Mel, can I bother you again? Should I move the flush in
> migrate_misplaced_transhuge_page() till after the ptl is taken?
> 

The flush, if it's necessary, needs to happen before the copy. However,
in this particular context it shouldn't matter.  In this specific context,
we must be dealing with a NUMA hinting fault which means the original PTE
is PROT_NONE, flushed and no writes are possible.  If a protection update
happens during the copy in migrate_misplaced_transhuge_page then it'll
be detected in migrate_misplaced_transhuge_page by the pmd_same check and
the page copy was a waste of time but otherwise harmless.

-- 
Mel Gorman
SUSE Labs

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>