From: Peter Zijlstra <peterz@infradead.org>
To: Nick Piggin <npiggin@suse.de>
Cc: Jan Kara <jack@suse.cz>,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [rfc][patch] mm: lockdep page lock
Date: Thu, 25 Mar 2010 10:40:05 +0100 [thread overview]
Message-ID: <1269510005.12097.26.camel@laptop> (raw)
In-Reply-To: <20100325053608.GB7493@laptop.nomadix.com>
On Thu, 2010-03-25 at 16:36 +1100, Nick Piggin wrote:
> On Wed, Mar 24, 2010 at 02:28:11PM +0100, Peter Zijlstra wrote:
> > On Tue, 2010-03-16 at 13:21 +1100, Nick Piggin wrote:
> > >
> > >
> > > Agreed (btw. Peter is there any way to turn lock debugging back on?
> > > it's annoying when cpufreq hotplug code or something early breaks and
> > > you have to reboot in order to do any testing).
> >
> > Not really, the only way to do that is to get the full system back into
> > a known (zero) lock state and then fully reset the lockdep state.
> >
> > It might be possible using the freezer, but I haven't really looked at
> > that, its usually simpler to simply fix the offending code or simply not
> > build it in your kernel.
>
> Right, but sometimes that is not possible (or you don't want to
> turn off cpufreq). I guess you could have an option to NOT turn
> it off in the first place. You could just turn off warnings, but
> leave everything else running, couldn't you?
>
> And then the option would just be to turn the printing back on.
Well, once there are cycles in the class graph you could end up finding
that cycle again and again. So the easiest option is to simply bail
after printing the acquisition that established the cycle.
Alternatively you'd have to undo the cycle creation and somehow mark a
class as bad and ignore it afterwards, which of course carries the risk
that you'll not detect other cycles which would depend on that class.
You could do as you suggest, but I would not trust the answers you get
after that because you already have cycles in the graph so interpreting
the things gets more and more interesting.
So non of the options really work well, and fixing, reverting or simply
not building is by far the easier thing to do.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2010-03-25 9:40 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-15 15:58 [rfc][patch] mm: lockdep page lock Nick Piggin
2010-03-15 18:08 ` Jan Kara
2010-03-16 2:21 ` Nick Piggin
2010-03-16 11:52 ` Jan Kara
2010-03-24 13:28 ` Peter Zijlstra
2010-03-25 5:36 ` Nick Piggin
2010-03-25 9:40 ` Peter Zijlstra [this message]
2010-03-26 3:18 ` Jamie Lokier
2010-03-26 6:54 ` Peter Zijlstra
2010-03-26 11:54 ` Jamie Lokier
2010-03-24 13:54 ` Peter Zijlstra
2010-03-16 6:20 ` Ingo Molnar
2010-03-16 6:42 ` Nick Piggin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1269510005.12097.26.camel@laptop \
--to=peterz@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=npiggin@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).