Re: [PATCH 1/1] mm: fix vma_copy for !CONFIG_PER_VMA_LOCK

[David Hildenbrand]

On 09.12.24 23:10, Suren Baghdasaryan wrote:
> vma_copy() function for !CONFIG_PER_VMA_LOCK configuration copies all
> fields using memcpy() as opposed to CONFIG_PER_VMA_LOCK version which
> copies only required fields. anon_vma_chain field should not be copied
> and new vma should instead initialize it to an empty list. Fix this
> by initializing anon_vma_chain inside vma_copy() function. The version
> of vma_copy() for CONFIG_PER_VMA_LOCK is fine since it does not change
> that field and anon_vma_chain of any new vma is already initialized and
> empty.

I'm wondering if there is sufficient reason to have two implementations 
to do the copying.

How expensive would it be to simply use the CONFIG_PER_VMA_LOCK variant 
unconditionally? Is it even measurable in fork() micro-benchmarks?

--
Cheers,

David / dhildenb