From: "Bart Van Assche" <bart.vanassche@gmail.com>
To: "Peter Zijlstra" <a.p.zijlstra@chello.nl>
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:45:43 +0200 [thread overview]
Message-ID: <e2e108260804291045k353e2ed0r4b14ba4820f6f156@mail.gmail.com> (raw)
In-Reply-To: <1209488643.6433.14.camel@lappy>
On Tue, Apr 29, 2008 at 7:04 PM, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
>
> I think the critical part is:
>
> > It really is invalid when considered against write locks.
>
> Aside from that it just states that inversion of lock order will be
> treated as invalid - even for read locks.
Inversion of recursive reader locks can't trigger a deadlock, even
when considered against write locks, as long as the rules are followed
I posted earlier. I invite anyone to come up with an example that
proves me wrong.
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.
Bart.
next prev parent reply other threads:[~2008-04-29 17:45 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 [this message]
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=e2e108260804291045k353e2ed0r4b14ba4820f6f156@mail.gmail.com \
--to=bart.vanassche@gmail.com \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--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
all inboxes | Powered by JetHome®