Re: R/W semaphore changes

[Ingo Molnar]

* David Howells <dhowells@xxxxxxxxxx> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/