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
