Messages in this thread | | | Date | Tue, 7 Dec 1999 15:45:00 -0500 | From | Johannes Erdfelt <> | Subject | Re: deadlock avoidance? |
| |
On Tue, Dec 07, 1999, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote: > > The problem is I acquire a spin lock before walking the list and release > > it when finished. > > Ok > > > I also acquire the same spin lock before modifying the list and release > > it when done. This is what causes the deadlock. I can possibly attempt > > to acquire the spin lock when it's already acquired inside the interrupt > > handler. > > This occurs in a couple of sound drivers too. I ended up with > > __dothing() which assumes you own the lock, and dothing() which is a wrapper > taking the lock and calling __dothing().
Hmm, this is a possibility but I think it would get complicated quickly. Just so you know, I'm running into this problem with USB and the new URBs interface.
I could export a __submit_urb interface which assumes the lock is held, but it would most likely be UHCI specific and needlessly complicate the interface.
This would also need to be done for __unlink_urb as well. I'd rather go with the add/delete queue instead. (option #2)
JE
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |