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
