Date: Mon, 23 Mar 2009 16:39:58 -0400
From: Kyle McMartin <kyle@mcmartin.ca>
To: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Kyle McMartin <kyle@mcmartin.ca>, Ingo Molnar <mingo@elte.hu>,
       mingo@redhat.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] degrade severity of lockdep printk
Message-ID: <20090323203958.GD19208@bombadil.infradead.org>
References: <20090323201628.GB19208@bombadil.infradead.org> <20090323202054.GA6395@elte.hu> <20090323202831.GC19208@bombadil.infradead.org> <1237840355.24918.80.camel@twins>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1237840355.24918.80.camel@twins>
User-Agent: Mutt/1.5.18 (2008-05-17)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 975
Lines: 21

On Mon, Mar 23, 2009 at 09:32:35PM +0100, Peter Zijlstra wrote:
> > Although I don't really see how this can be particularly fixed, since
> > any workload that allocates a struct with a lock, initializes, and then
> > eventually frees it a whole bunch of times will run out of lock_lists
> > won't it?
> 
> Not if the lock init site doesn't change. Modules are the big exception,
> cycling modules will run you out of lockdep space..
> 

Somewhat confused by this... possibly I'm just being thick and missing
some subtlety though, but surely the context is equally important?
I mean, the locks held on entry to, say, a fs_operations struct member
function could be different on every different possible callpath...

regards, Kyle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/