From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Bart Van Assche <bart.vanassche@gmail.com>
Cc: ego@in.ibm.com, linux-kernel@vger.kernel.org,
Zdenek Kabelac <zdenek.kabelac@gmail.com>,
Oleg Nesterov <oleg@tv-sign.ru>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
"Rafael J. Wysocki" <rjw@sisk.pl>,
Andrew Morton <akpm@linux-foundation.org>,
Ingo Molnar <mingo@elte.hu>,
Srivatsa Vaddagiri <vatsa@in.ibm.com>
Subject: Re: [PATCH 1/8] lockdep: fix recursive read lock validation
Date: Tue, 29 Apr 2008 19:58:32 +0200 [thread overview]
Message-ID: <1209491912.6433.36.camel@lappy> (raw)
In-Reply-To: <e2e108260804291045k353e2ed0r4b14ba4820f6f156@mail.gmail.com>
On Tue, 2008-04-29 at 19:45 +0200, Bart Van Assche wrote:
> Let's return to the starting point of this discussion. The patch at
> the start of this thread forbids to invert the lock order of reader
> locks. Why to forbid this if it can't trigger a deadlock ? At least in
> user space code, it's quite easy to trigger such inversion. In
> sufficiently complex code where functions call other functions while
> holding a reader lock, reader lock inversion can be hard to avoid.
Sure, but the whole point is: lockdep cannot track those rules. _that_
is why I'm choosing to forbid them.
Also, on Linux only rwlock_t allows reader recursion, and that lock type
really ought to die, all users should convert to RCU (if possible).
So I'm not thinking placing this restriction on kernel code is going to
be painful.
next prev parent reply other threads:[~2008-04-29 17:59 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-29 12:56 [PATCH 0/8] CPU-Hotplug: Fix CPU-Hotplug <--> cpufreq locking dependency Gautham R Shenoy
2008-04-29 12:57 ` [PATCH 1/8] lockdep: fix recursive read lock validation Gautham R Shenoy
2008-04-29 13:16 ` Bart Van Assche
2008-04-29 14:57 ` Peter Zijlstra
2008-04-29 15:03 ` Bart Van Assche
2008-04-29 15:15 ` Peter Zijlstra
2008-04-29 16:03 ` Bart Van Assche
2008-04-29 16:15 ` Peter Zijlstra
2008-04-29 16:29 ` Bart Van Assche
2008-04-29 17:04 ` Peter Zijlstra
2008-04-29 17:45 ` Bart Van Assche
2008-04-29 17:58 ` Peter Zijlstra [this message]
2008-04-29 12:58 ` [PATCH 2/8] lockdep: reader-in-writer recursion Gautham R Shenoy
2008-04-29 13:00 ` [PATCH 3/8] lockdep: fix fib_hash softirq inversion Gautham R Shenoy
2008-04-29 14:45 ` Peter Zijlstra
2008-04-29 13:01 ` [PATCH 4/8] net: af_netlink: deadlock Gautham R Shenoy
2008-04-29 13:19 ` Hans Reiser, reiserfs developer linux-os (Dick Johnson)
2008-04-29 13:02 ` [PATCH 5/8] cpu: cpu-hotplug deadlock Gautham R Shenoy
2008-04-29 14:33 ` Oleg Nesterov
2008-04-29 15:09 ` Peter Zijlstra
2008-04-29 16:45 ` Oleg Nesterov
2008-04-29 17:31 ` Peter Zijlstra
2008-04-30 5:37 ` Gautham R Shenoy
2008-04-30 11:43 ` Oleg Nesterov
2008-04-29 13:02 ` [PATCH 6/8] lockdep: annotate cpu_hotplug Gautham R Shenoy
2008-04-29 13:03 ` [PATCH 7/8] cpu_hotplug: Introduce try_get_online_cpus() Gautham R Shenoy
2008-04-29 13:05 ` [PATCH 8/8] cpufreq: Nest down_write/read(cpufreq_rwsem) within get_online_cpus()/put_online_cpus() Gautham R Shenoy
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=1209491912.6433.36.camel@lappy \
--to=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=bart.vanassche@gmail.com \
--cc=ego@in.ibm.com \
--cc=heiko.carstens@de.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=oleg@tv-sign.ru \
--cc=rjw@sisk.pl \
--cc=vatsa@in.ibm.com \
--cc=zdenek.kabelac@gmail.com \
/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