public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Remy Bohmer <linux@bohmer.net>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Daniel Walker <dwalker@mvista.com>,
	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, 8 Dec 2007 21:08:01 +0100	[thread overview]
Message-ID: <20071208200801.GC579@elte.hu> (raw)
In-Reply-To: <3efb10970712081152o2d4abcfbo634a8d2445c09699@mail.gmail.com>


* Remy Bohmer <linux@bohmer.net> wrote:

> But... now we do not transfer the dev->sem to a mutex, because lockdep 
> will start generating false positives, and thus we mask the lockdep 
> error, by not converting the dev->sem to what it really is...

no, you are wrong. If you want to do complex locking, you can still do 
it: take a look at the dev->sem conversion patches from Peter which 
correctly do this. Lockdep has all the facilities for that. (you just 
dont know about them) Currently there are 4459 critical sections in the 
kernel that use mutexes and which work fine with lockdep.

the general policy message here is: do not implement complex locking. It 
hurts. It's hard to maintain. It's easy to mess up and leads to bugs. 
Lockdep just makes that plain obvious.

Your mail and your frustration shows this general concept in happy 
action: judging from your comments you have little clue about dev->sem 
locking and its implications and you'd happily go along and pollute the 
kernel with complex and hard to maintain nested locking constructs.

Lockdep prevents you from doing it mindlessly, it _forces_ you to first 
understand the data structures, their locking and their relationship 
with each other. Then you can implement complexity, if you still want 
it.

That, Sir, is a Good Thing (tm).

	Ingo

  parent reply	other threads:[~2007-12-08 20:08 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
2007-12-08 20:08             ` Ingo Molnar [this message]
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=20071208200801.GC579@elte.hu \
    --to=mingo@elte.hu \
    --cc=dgc@sgi.com \
    --cc=dwalker@mvista.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@bohmer.net \
    --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