lkml.org 
[lkml]   [1999]   [Dec]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.081 / U:0.160 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site