On Thu, Apr 09, 2015 at 04:07:55PM -0400, Waiman Long wrote: > The qrwlock is fair in the process context, but becoming unfair when > in the interrupt context to support use cases like the tasklist_lock. > However, the unfair code in the interrupt context has problem that > may cause deadlock. > > The fast path increments the reader count. In the interrupt context, > the reader in the slowpath will wait until the writer release the > lock. However, if other readers have the lock and the writer is just > in the waiting mode. It will never get the write lock because the > that interrupt context reader has increment the count. This will > cause deadlock. > > This patch fixes this problem by checking the state of the > reader/writer count retrieved at the fast path. If the writer > is in waiting mode, the reader will get the lock immediately and > return. Otherwise, it will wait until the writer release the lock > like before. A little word on how you found this issue would be nice. I'll have a look at the actual patch tomorrow, my brain is properly fried (as demonstrated by my last email to you ;-). -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
