public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jarek Poplawski <jarkao2@gmail.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Remy Bohmer <linux@bohmer.net>,
	Daniel Walker <dwalker@mvista.com>, Ingo Molnar <mingo@elte.hu>,
	Steven Rostedt <rostedt@goodmis.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Dave Chinner <dgc@sgi.com>
Subject: Re: lockdep problem conversion semaphore->mutex (dev->sem)
Date: Sat, 08 Dec 2007 23:57:45 +0100	[thread overview]
Message-ID: <475B2169.6030709@gmail.com> (raw)
In-Reply-To: <1197147016.6353.53.camel@lappy>

Peter Zijlstra wrote, On 12/08/2007 09:50 PM:

> On Sat, 2007-12-08 at 21:33 +0100, Remy Bohmer wrote:
> 
>> Which problems? I did not see any special things, it looked rather
>> straight forward. What have I overlooked?
> 
> On suspend it locks the whole device tree, this means it has 'unbounded'
> nesting and holds an 'unbounded' number of locks. Neither things are
> easy to annotate (remember that mutex_lock_nested can handle up to 8
> nestings and current->held_locks has a max of 30).
> 
> In fact, converting this will be the hardest part, it would require
> reworking the locking and introduction of a hard limit on the device
> tree depth - this might upset some people, but I suspect that 16 or 24
> should be deep enough for pretty much anything. Of course, if people
> prove me wrong, I'll have to reconsider. The up-side of the locking
> scheme I'm thinking of will be that locking the whole tree will only
> take 'depth' number of opterations vs the total number of tree elements.

Of course, I don't know the problem enough, and would be glad if somebody
give me a hint, but I wonder why so deep nesting with lockdep's modification
is necessary here? Does buses have parent buses and so on x8? Why isn't
here considered creating of different lockdep classes according to types
of buses and devices "the usual way"? This way seems to be quite easy in
later debugging.

Regards,
Jarek P.

  parent reply	other threads:[~2007-12-08 22:56 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-07 23:02 lockdep problem conversion semaphore->mutex (dev->sem) Remy Bohmer
2007-12-08 12:16 ` Peter Zijlstra
2007-12-08 16:53   ` Daniel Walker
2007-12-08 17:11     ` Peter Zijlstra
2007-12-08 17:06       ` Daniel Walker
2007-12-08 17:36         ` Peter Zijlstra
2007-12-08 19:52           ` Remy Bohmer
2007-12-08 20:04             ` Peter Zijlstra
2007-12-08 20:33               ` Remy Bohmer
2007-12-08 20:50                 ` Peter Zijlstra
2007-12-08 20:55                   ` Remy Bohmer
2007-12-08 22:57                   ` Jarek Poplawski [this message]
2007-12-08 20:08             ` Ingo Molnar
2007-12-08 20:48               ` Remy Bohmer

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=475B2169.6030709@gmail.com \
    --to=jarkao2@gmail.com \
    --cc=dgc@sgi.com \
    --cc=dwalker@mvista.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@bohmer.net \
    --cc=mingo@elte.hu \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox