All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.