From: Ingo Molnar <mingo@elte.hu>
To: David Howells <dhowells@redhat.com>
Cc: Arjan van de Ven <arjan@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
torvalds@osdl.org, akpm@osdl.org, linux-kernel@vger.kernel.org
Subject: Re: R/W semaphore changes
Date: Tue, 4 Jul 2006 15:21:35 +0200 [thread overview]
Message-ID: <20060704132135.GA7816@elte.hu> (raw)
In-Reply-To: <15345.1152018339@warthog.cambridge.redhat.com>
* David Howells <dhowells@redhat.com> wrote:
> They still aren't allowed to. Consider:
>
> CPU 1 CPU 2
> ======================= =======================
> -->down_read(&A);
> <--down_read(&A);
> -->down_write(&A);
> --- SLEEPING ---
> -->down_read(&A);
> --- DEADLOCKED ---
i think you misunderstood what nested locking means in the lockdep case.
(and that is my fault, for not adding enough documentation to
down_write_nested() and down_read_nested().)
nested locking does not mean the same instance is allowed to nest! It
only allows different-instance nesting, 'nesting within the same lock
class'. (Lockdep has a very broad notion of 'lock class', to achieve the
collection of very generic locking rules and to do as generic validation
as possible. See Documentation/lockdep-design.txt for more details.)
Rw-locks on the other hand have special permission to nest for the same
instance too. See commit 6c9076ec9cd448f43bbda871352a7067f456ee26:
lockdep so far only allowed read-recursion for the same lock instance.
This is enough in the overwhelming majority of cases, but a hostap case
triggered and reported by Miles Lane relies on same-class
different-instance recursion. So we relax the restriction on read-lock
recursion.
(This change does not allow rwsem read-recursion, which is still
forbidden.)
also please see the testcases in lib/locking-selftest.c, we specifically
test the rwsem scenario you outlined above, to make sure the validator
immediately flags it:
------------------------
| Locking API testsuite:
----------------------------------------------------------------------------
| spin |wlock |rlock |mutex | wsem | rsem |
--------------------------------------------------------------------------
[...]
recursive read-lock: | ok | | ok |
recursive read-lock #2: | ok | | ok |
[...]
Ingo
next prev parent reply other threads:[~2006-07-04 13:26 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-04 12:47 R/W semaphore changes David Howells
2006-07-04 12:52 ` Arjan van de Ven
2006-07-04 13:05 ` David Howells
2006-07-04 13:17 ` Arjan van de Ven
2006-07-04 13:21 ` Ingo Molnar [this message]
2006-07-04 13:33 ` [patch] lockdep: add more rwsem.h documentation Ingo Molnar
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=20060704132135.GA7816@elte.hu \
--to=mingo@elte.hu \
--cc=akpm@osdl.org \
--cc=arjan@infradead.org \
--cc=dhowells@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=torvalds@osdl.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.