On Mon, Jul 17, 2017 at 11:02 AM, Nadav Amit <namit@xxxxxxxxxx> wrote: > Setting and clearing mm->tlb_flush_pending can be performed by multiple > threads, since mmap_sem may only be acquired for read in task_numa_work. > If this happens, tlb_flush_pending may be cleared while one of the > threads still changes PTEs and batches TLB flushes. > > As a result, TLB flushes can be skipped because the indication of > pending TLB flushes is lost, for instance due to race between > migration and change_protection_range (just as in the scenario that > caused the introduction of tlb_flush_pending). > > The feasibility of such a scenario was confirmed by adding assertion to > check tlb_flush_pending is not set by two threads, adding artificial > latency in change_protection_range() and using sysctl to reduce > kernel.numa_balancing_scan_delay_ms. This thing is logically a refcount. Should it be refcount_t? --Andy -- 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>
