Re: [PATCH 0/6] mm: Make per-VMA locks available in all builds

[Dave Hansen <dave.hansen@intel.com>]

On 5/8/26 09:52, Lorenzo Stoakes wrote:
...
>>  * Can the helper avoid the goto, maybe by taking the VMA refcount
>>    while holding mmap_lock?
> 
> Surely that'd defeat the purpose of VMA locks though? you'd hold the mmap lock
> for less time but you're still contending vs. _any_ VMA write locks whilst
> trying to get a VMA read lock?
> 
> Unless it's on a slow path... hmm :)

Yup. It's in a slow path. the example helper I had here does:

retry:
	vma = lock_vma_under_rcu(mm, address);
	if (vma)
		return vma;
	mmap_read_lock(mm);
	vma = vma_lookup(mm, address);
	mmap_read_unlock(mm);	
	goto retry;

It avoids mmap_lock in the common, fast case. I was hoping to replace it
with something like:

	vma = lock_vma_under_rcu(mm, address);
	if (vma)
		return vma;
	mmap_read_lock(mm);
	vma = vma_lookup(mm, address);
	vma_start_read(vma->vm_mm, vma); // Is this safe?
	mmap_read_unlock(mm);	
	return vma;

Which still uses mmap_lock, but avoids the goto. I'm pretty sure the
first one doesn't have any locking problems. The second one, I need to
think about a _lot_ more.