Re: [PATCH] lockdep: lock_set_subclass - reset a held lock's subclass

[Linus Torvalds <torvalds@linux-foundation.org>]

On Fri, 1 Aug 2008, Jeremy Fitzhardinge wrote:
> 
> I have a function traversing a pagetable in vaddr order (low to high), taking
> pte locks as it builds up batches of pte page updates.  When the batch is
> issued, it releases all the locks, and won't end up holding more than ~16 at a
> time.

Hmm. 

With hashed locks, that is _not_ safe in general. Now, it may well be safe 
in your case, so I'm not going to say you have a bug, but even if you do 
them in vaddr order, the thing is, we don't guarantee that the _locks_ are 
ordered in virtual address order.

Right now, I think the pte locks are either a single one per mm (in which 
case I assume you don't take any lock at all), or it's a lock that is 
embedded in the pmd page iirc.

What if you have pmd sharing through some shared area being mapped at two 
different processes at different addresses? Yeah, I don't think we share 
pmd's at all (except if you use hugetables and for the kernel), but it's 
one of those things where subtle changes in how the pte lock allocation 
could cause problems.

Eg, I could easily see somebody doing the pte lock as a hash over not just 
the address, but the "struct mm" pointer too. At which point different 
parts of the address space might even share the PTE lock, and you'd get 
deadlocks even without any ABBA behavior, just because the pte lock might 
be A B C A or something inside the same process.

			Linus