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

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

... adding all the cc's back.

On 4/30/26 07:20, Andrew Morton wrote:
> On Wed, 29 Apr 2026 11:19:54 -0700 Dave Hansen <dave.hansen@linux.intel.com> wrote:
> 
>> When working on some x86 shadow stack code, it was a real pain to
>> avoid causing recursive locking problems with mmap_lock. One way
>> to avoid those was to avoid mmap_lock and use per-VMA locks instead.
>> They are great, but they are not available in all configs which
>> makes them unusable in generic code, or if you want to completely
>> avoid mmap_lock.
> 
> Did you see the AI review?
> 	https://sashiko.dev/#/patchset/20260429181954.F50224AE@davehans-spike.ostc.intel.com

I just went through it. There was some absolutely valid stuff in there
like a bunch of CONFIG_PER_VMA_LOCK references needing to be cleaned up.
It also made some good points about the binder shrinker sites that I
think I cleaned up for v2.

There are three very valid structural problems that it's concerned about.

First is that lock_vma_under_rcu_wait() doesn't use
mmap_read_lock_killable(). It probably needs to, or at least there would
need to be killable and non-killable variants. That's easy enough to do
if folks agree that this is overall something that should go forward.
I'd prefer to hand wave it away for the moment, though.

Second, it brings up concerns about lock_vma_under_rcu_wait() deadlocks
in the face of other per-VMA or mmap_lock holders. This is very valid,
but it's inherent for users of mmap_lock. I think it's just a
documentation issue.

Third, Sashiko is _very_ peeved about the lock_vma_under_rcu_wait() goto
loop. Broadly, it's concerned about fairness and livelocks in the face
of userspace being able to compel 'goto retry' to happen forever. It's a
valid theoretical concern for sure. I'm less convinced that it will be a
problem in practice, and I should probably hack together a torture test
to see how many retries actually happen.

The other way to fix it more robustly would be to acquire the vma
reference under the existing mmap_read_lock(). I _think_ it's just a
couple extra lines of code, but I haven't done the legwork to flesh out
how that would look.

But the key questions for this series remain:
 1. Should/can per-VMA locking be available in all configs?
 2. Is *a* lock_vma_under_rcu_wait() implementation feasible and useful?
    The implementation in this series is highly imperfect. Is there a
    chance of a better one or is it just impossible?