Thread (117 messages) 117 messages, 14 authors, 2013-02-19

Re: [PATCH v5 01/45] percpu_rwlock: Introduce the global reader-writer lock backend

From: Srivatsa S. Bhat <hidden>
Date: 2013-01-22 20:00:30
Also in: linux-arch, linux-arm-kernel, linuxppc-dev, lkml, netdev

On 01/23/2013 01:02 AM, Steven Rostedt wrote:
On Tue, 2013-01-22 at 13:03 +0530, Srivatsa S. Bhat wrote:
quoted
A straight-forward (and obvious) algorithm to implement Per-CPU Reader-Writer
locks can also lead to too many deadlock possibilities which can make it very
hard/impossible to use. This is explained in the example below, which helps
justify the need for a different algorithm to implement flexible Per-CPU
Reader-Writer locks.

We can use global rwlocks as shown below safely, without fear of deadlocks:

Readers:

         CPU 0                                CPU 1
         ------                               ------

1.    spin_lock(&random_lock);             read_lock(&my_rwlock);


2.    read_lock(&my_rwlock);               spin_lock(&random_lock);


Writer:

         CPU 2:
         ------

       write_lock(&my_rwlock);
I thought global locks are now fair. That is, a reader will block if a
writer is waiting. Hence, the above should deadlock on the current
rwlock_t types.
Oh is it? Last I checked, lockdep didn't complain about this ABBA scenario!
We need to fix those locations (or better yet, remove all rwlocks ;-)
:-)

The challenge with stop_machine() removal is that the replacement on the
reader side must have the (locking) flexibility comparable to preempt_disable().
Otherwise, that solution most likely won't be viable because we'll hit way
too many locking problems and go crazy by the time we convert them over..(if
we can, that is!)

Regards,
Srivatsa S. Bhat
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help