lkml.org 
[lkml]   [2008]   [Aug]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] lockdep: lock_set_subclass - reset a held lock's subclass


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


\
 
 \ /
  Last update: 2008-08-01 21:29    [W:0.068 / U:0.336 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site