Re: [PATCH v4 07/20] mm/vma: fix self-merge check in copy_vma()

On 8/11/26 18:51, Lorenzo Stoakes (ARM) wrote:
> On Tue, Aug 11, 2026 at 06:44:01PM +0200, David Hildenbrand (Arm) wrote:
>>>
>>> Since copy_vma_and_data() which calls copy_vma() intends to reference the
>>> old VMA after the merge, it must have this pointer updated.
>>>
>>> This kind of self-merge is not possible with a succeeding merge, as the
>>> merge always prefers to expand the preceding VMA if possible.
>>>
>>> copy_vma() accounts for this by explicitly checking to see if a self-merge
>>> occurred and updating the vmap pointer if so. However it incorrect did so
>>> even for a subsequent merge (this is simply a noop so it had no impact).
>>
>> Took me longer than it should to find out that this is no real fix ;)
>>
>>>
>>> So change this to only check for the case which matters - a backwards
>>> merge - and rearrange the parameters to make it clearer we're doing that -
>>> i.e. check new_vma->vm_start < old_vma_start (having already renamed
>>> vma_start to old_vma_start to make it clear this is the previous VMA).
>>>
>>> Also update the existing wall-of-text comment to be a lot clearer.
>>>
>>> While we're here, replace the VM_BUG_ON_VMA() with a VM_WARN_ON_ONCE_VMA()
>>> and update the VMA userland tests accordingly.
>>>
>>> No functional change intended.
>>>
>>> Signed-off-by: Lorenzo Stoakes (ARM) <[email protected]>
>>> ---
>> I skimmed over it, looks correct, but the merging stuff is way over my head to
>> confidentially give a RB tag her :)
> 
> Well that's what A-b is for ;)

Assisted-by? Half-assed-by?

;)

Acked-by: David Hildenbrand (Arm) <[email protected]>

-- 
Cheers,

David