Andy Lutomirski <luto@xxxxxxxxxx> wrote: > 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? I don’t think so. refcount_inc() would WARN_ONCE if the counter is zero before the increase, although this is a valid scenario here. -- 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
