From: Ben Greear <greearb@candelatech.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@kernel.org>
Subject: Re: Question on lockdep and MAX_LOCK_DEPTH
Date: Tue, 05 Feb 2013 18:17:12 -0800 [thread overview]
Message-ID: <5111BD28.50407@candelatech.com> (raw)
In-Reply-To: <20130206015430.GA9161@home.goodmis.org>
On 02/05/2013 05:54 PM, Steven Rostedt wrote:
> I'm not sure the swapper task is part of the 'do_each_thread()' loop.
>
> Perhaps what you want to do is add a:
>
> lockdep_print_held_locks(current);
I'll add that and test...
> I'm curious. Does your code grab a read lock? If you grab the same read
> lock multiple times it adds to the list each time. Thus if you have
> anything like:
>
> for (i = 0; i < 100; i++ ) {
> read_lock(&lock);
> }
>
> for (i = 0; i < 100; i++) {
> read_unlock(&lock);
> }
>
> That will fill up the held locks quite a bit.
>
> The above code I showed is ridiculous and I doubt you have it, but if
> you have something that does lots of recursive reads for some reason,
> that could be an issue.
I have only one read/write lock in my module, and it looks like
I always lock it as a writer (will fix that soon for performance
reasons, but it should be valid locking I think).
I have no rcu locks at all in my module currently.
I've seen similar lockups on another machine that does not use
this module, but it uses a hacked up pktgen. I haven't found
a test case that reproduces this on a clean upstream build,
but I am still fairly suspicious that it isn't my code.
Famous last words I'm sure :)
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
next prev parent reply other threads:[~2013-02-06 2:19 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-06 1:10 Question on lockdep and MAX_LOCK_DEPTH Ben Greear
2013-02-06 1:54 ` Steven Rostedt
2013-02-06 2:17 ` Ben Greear [this message]
2013-02-06 2:26 ` Ben Greear
2013-02-06 2:52 ` Steven Rostedt
2013-02-06 3:30 ` Ben Greear
2013-02-06 4:36 ` Steven Rostedt
2013-02-06 6:23 ` Ben Greear
2013-02-06 13:21 ` Steven Rostedt
2013-02-06 15:56 ` Ben Greear
2013-02-06 16:07 ` Steven Rostedt
2013-02-06 16:39 ` Ingo Molnar
2013-02-06 16:46 ` Steven Rostedt
2013-02-06 16:58 ` Ben Greear
2013-02-06 17:03 ` Steven Rostedt
2013-02-06 4:26 ` Steven Rostedt
2013-02-06 6:20 ` Ben Greear
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=5111BD28.50407@candelatech.com \
--to=greearb@candelatech.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.