Re: [PATCH v1] mm: fix PageAnonExclusive clearing racing with concurrent RCU GUP-fast

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 02.09.22 00:35, Andrew Morton wrote:
> On Thu,  1 Sep 2022 10:35:59 +0200 David Hildenbrand <david@xxxxxxxxxx> wrote:
> 
>> The possible issues due to reordering are of theoretical nature so far
>> and attempts to reproduce the race failed.
>>
>> Especially the "no PTE change" case isn't the common case, because we'd
>> need an exclusive anonymous page that's mapped R/O and the PTE is clean
>> in KSM code -- and using KSM with page pinning isn't extremely common.
>> Further, the clear+TLB flush we used for now implies a memory barrier.
>> So the problematic missing part should be the missing memory barrier
>> after pinning but before checking if the PTE changed.
> 
> Obscure bug, large and tricky patch.  Is a -stable backport really
> justifiable?

Fair question, was asking myself the same. As you're wondering about the
same, I don't think so. Let's drop it.

Out of the CONFIG_HAVE_FAST_GUP supporting architectures primarily only
the 32bit architectures can even lose the PageAnonExclusive during
swapout (until we make them all preserve it in the swp PTE), the other
ones already support preserve it.

So unless fork() would be involved at the wrong time as well,  x86-64,
s390x, aarch64, ppc64 book3s ... wouldn't even have a real issue with
this race.

(note that the actual code changes are small -- but yes, I think
linux-stable rules always consider the full patch LOC)

-- 
Thanks,

David / dhildenb





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux