[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <48935FA4.5010804@goop.org>
Date: Fri, 01 Aug 2008 12:10:28 -0700
From: Jeremy Fitzhardinge <jeremy@...p.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
CC: Peter Zijlstra <a.p.zijlstra@...llo.nl>,
David Miller <davem@...emloft.net>, mingo@...e.hu,
linux-kernel@...r.kernel.org, akpm@...ux-foundation.org
Subject: Re: [PATCH] lockdep: lock_set_subclass - reset a held lock's subclass
Linus Torvalds wrote:
> On Fri, 1 Aug 2008, Jeremy Fitzhardinge wrote:
>
>> Hey, can I use this to suppress the spurious lockdep warnings I get when I try
>> to hold more than one pte lock at once?
>>
>
> So how sure are you that they are spurious?
>
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.
So, I think this is OK. There are no internal lock ordering issues, and
I don't think there'll be any bad interactions from someone trying to
take pte locks for two separate pagetables. I don't think there's
anyone else trying to take more than one pte lock at once, but if there
were "lock low vaddr then high" seems like a reasonable locking rule (or
more precisely "lowest" to deal with the case of a pte page being
aliased at multiple vaddrs).
Lockdep complains because the split pte locks are all in the same lock
class, so it reports it as taking a spinlock recursively. I'd reported
this to PeterZ before, and he responded with "uh, I'll think about
it...", which I took to mean "...when someone else has a problem". So
I'm wondering if this is that time...
(This is all with split pte locks, obviously.)
J
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists