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 16:57:30 +0200 [thread overview]
Message-ID: <1209481050.13978.72.camel@twins> (raw)
In-Reply-To: <e2e108260804290616l489ac8c2udcb2e80fc268b72b@mail.gmail.com>
On Tue, 2008-04-29 at 15:16 +0200, Bart Van Assche wrote:
> On Tue, Apr 29, 2008 at 2:57 PM, Gautham R Shenoy <ego@in.ibm.com> wrote:
> > Subject: lockdep: fix recursive read lock validation
> > This means that the following sequence is now invalid, whereas previously
> > it was considered valid:
> >
> > rlock(a); rlock(b); runlock(b); runlock(a)
> > rlock(b); rlock(a);
>
> Why are you marking this sequence as invalid ? Although it can be
> debated whether it is good programming practice to be inconsistent
> about the order of read-locking, the above sequence can't be involved
> in a deadlock.
Not for pure read locks, but when you add write locks to it, it does get
deadlocky. Lockdep does not keep separate chains for read and write
locks.
next prev parent reply other threads:[~2008-04-29 14:57 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 [this message]
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
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=1209481050.13978.72.camel@twins \
--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