Re: [PATCH mm-unstable v2] mm/hugetlb_vmemmap: fix race with speculative PFN walkers

From: Muchun Song
Date: Thu Jun 27 2024 - 22:36:30 EST




> On Jun 28, 2024, at 07:04, Yu Zhao <yuzhao@xxxxxxxxxx> wrote:
>
> On Thu, Jun 27, 2024 at 4:47 PM Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
>>
>> On Thu, 27 Jun 2024 16:27:05 -0600 Yu Zhao <yuzhao@xxxxxxxxxx> wrote:
>>
>>> While investigating HVO for THPs [1], it turns out that speculative
>>> PFN walkers like compaction can race with vmemmap modifications, e.g.,
>>>
>>> CPU 1 (vmemmap modifier) CPU 2 (speculative PFN walker)
>>> ------------------------------- ------------------------------
>>> Allocates an LRU folio page1
>>> Sees page1
>>> Frees page1
>>>
>>> Allocates a hugeTLB folio page2
>>> (page1 being a tail of page2)
>>>
>>> Updates vmemmap mapping page1
>>> get_page_unless_zero(page1)
>>>
>>> Even though page1->_refcount is zero after HVO, get_page_unless_zero()
>>> can still try to modify this read-only field, resulting in a crash.
>>
>> Ah. So we should backport this into earlier kernels, yes?
>>
>> Are we able to identify a Fixes: for this? Looks difficult.
>>
>> This seems quite hard to trigger. Do any particular userspace actions
>> invoke the race?
>
> Yes, *very* hard to trigger:
> 1. Most hugeTLB use cases I know of are static, i.e., reserved at boot
> time, because allocating at runtime is not reliable at all.
> 2. On top of that, someone has to be very unlucky to get tripped over
> above, because the race window is so small -- I wasn't able to trigger
> it with a stress testing that does nothing but that (with THPs
> though).
>
> So I don't think it's worth cc'ing stable, unless Muchun recommends.

I agree with Yu.

Thanks.