Messages in this thread | | | Date | Fri, 12 Jun 2015 23:16:15 -0400 | From | Waiman Long <> | Subject | Re: [PATCH v2 1/2] locking/qrwlock: Fix bug in interrupt handling code |
| |
On 06/11/2015 10:21 AM, Will Deacon wrote: > Hi Waiman, > > On Tue, Jun 09, 2015 at 04:19:12PM +0100, 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. > I'm probably just being thick here, but I'm struggling to understand the > deadlock case. > > If a reader enters the slowpath in interrupt context, we spin while > (cnts& _QW_WMASK) == _QW_LOCKED. Consequently, if there is a writer in > the waiting state, that won't hold up the reader and so forward progress > is ensured. When the reader unlocks, the reader count is decremented and > the writer can take the lock. > > The only problematic case I can think of is if you had a steady stream of > readers in interrupt context, but that doesn't seem likely (and I don't > think this patch deals with that anyway). > > What am I missing? > > Will
You are right. It was my mistake. I misread my own code. I should have a comment to clarify that. I will send out a revised one next week.
Cheers, Longman
| |