Re: [PATCH v7 1/5] mm: Make per-VMA locks available universally

[David Hildenbrand (Arm)]

On 9/10/26 16:50, Suren Baghdasaryan wrote:
> On Thu, Sep 10, 2026 at 3:09 AM David Hildenbrand (Arm)
> <david@xxxxxxxxxx> wrote:
>>
>> On 8/31/26 22:30, Suren Baghdasaryan wrote:
>>> From: Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx>
>>>
>>> The per-VMA locks have been around for several years. They've had some
>>> bugs worked out of them and have seen quite wide use. However, they
>>> are still only available when architectures explicitly enable them.
>>> Remove the conditional compilation around the per-VMA locks, making
>>> them available on all architectures and configs.
>>>
>>> The approach up to now seemed to be to add ARCH_SUPPORTS_PER_VMA_LOCK
>>> when the architecture started using per-VMA locks in the fault
>>> handler. But, contrary to the naming, the Kconfig option does not
>>> really indicate whether the architecture supports per-VMA locks or
>>> not. It is more of a marker for whether the architecture is likely to
>>> benefit from per-VMA locks.
>>>
>>> To me, the most important thing side-effect of universal availability
>>> is letting per-VMA locks be used in SMP=n configs. This lets us use
>>> per-VMA locking in all x86 code without fallbacks.
>>>
>>> Overall, this just generally makes the kernel simpler. Just look at
>>> the diffstat. It also opens the door to users that want to use the
>>> per-VMA locks in common code. Doing *that* brings additional
>>> simplifications.
>>>
>>> The downside of this is adding some fields to vm_area_struct and
>>> mm_struct. There are likely ways to optimize this, especially for
>>> things like SMP=n configs. For now, do the simplest thing: use the
>>> same implementation everywhere.
>>>
>>> == Considerations for NOMMU config ==
>>
>> Echoing what I commented on v6 after v7 was already sent (not realizing there
>> was a v7 after my inbox got flooded)
>>
>> Maybe the NOMMU "support" could have been had in a separate prep patch (where a
>> lot of the description below could have been moved), making the patch itself
>> just mostly a removal of code.
> 
> Yeah, that would make reviewing indeed easier. I guess current
> structure is the result of me adding NOMMU pieces to the pre-existing
> patchset. I don't think it's worth refactoring but I can do that if
> you insist.

I won't insist, it was just commenting because it would cleanly separate the
NOMMU oddity from just unlocking it in common code and removing the leftovers :)

-- 
Cheers,

David