On Tue, Dec 10, 2024 at 1:06 AM David Hildenbrand <david@xxxxxxxxxx> wrote: > > 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? Yeah, the benefit if any would be tiny. I'll try measuring the difference and if it's not visible will remove the !CONFIG_PER_VMA_LOCK version. Thanks! > > -- > Cheers, > > David / dhildenb >
