Messages in this thread |  | | Date | Thu, 09 Apr 2015 18:09:55 -0400 | From | Waiman Long <> | Subject | Re: [PATCH] qrwlock: Fix bug in interrupt handling code |
| |
On 04/09/2015 04:14 PM, Peter Zijlstra wrote: > 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.
It is not found by testing. I didn't see any problem with a running Linux kernel so far.
I am in the process of trying to make the qrwlock lock unfair in virt. When I inspect the code, I found out that the interrupt code didn't look right. That is why I send out a patch to fix that.
Regards, Longman
|  |