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

[Andy Lutomirski <luto@kernel.org>]

On Mon, Jul 17, 2017 at 6:40 PM, Nadav Amit <nadav.amit@gmail.com> wrote:
> Andy Lutomirski <luto@kernel.org> wrote:
>
>> On Mon, Jul 17, 2017 at 11:02 AM, Nadav Amit <namit@vmware.com> 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.
>

Hmm.  Maybe a refcount that starts at 1?  My point is that, if someone
could force it to overflow, it would be bad.  Maybe this isn't worth
worrying about.

--
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>