Re: [PATCH] RCU safety for vma maple tree walks

[Andi Kleen <andi@firstfloor.org>]

> 
> Did you check this with lockdep?

Yes all tests were running with lockdep, and it didn't trigger.

> 
> Any access to the maple tree without holding the write lock or the rcu
> read lock will cause lockdep to complain.

Hmm, seems that's not working for some reason?

The VM callers of for_each_vma clearly don't take rcu read locks.

> 
> Likewise, any sleeping while holding the rcu read lock would produce
> warnings.

Right but the walkers don't use the read lock.
 
> Note that you do not need to hold the rcu read lock on the vma maple
> tree if you have the write lock.  This looks to be the case for most (or
> all?) of the cases you have below.

Yes the write lock is hold (like I discussed).  The problem isn't parallel
modification but that splitting during the walk invalidates the
iterator caching if you sleep too. That's all purely on the local
thread. The only contribution from others is to cause more sleeping
due to memory pressure or rescheduling.

-Andi