| To: | Roland Dreier <roland@xxxxxxxxxxx> |
|---|---|
| Subject: | Re: LLTX and netif_stop_queue |
| From: | jamal <hadi@xxxxxxxxxx> |
| Date: | 19 Dec 2004 18:06:32 -0500 |
| Cc: | "David S. Miller" <davem@xxxxxxxxxxxxx>, netdev@xxxxxxxxxxx, openib-general@xxxxxxxxxx |
| In-reply-to: | <52fz21ncgh.fsf@topspin.com> |
| Organization: | jamalopolous |
| References: | <52llbwoaej.fsf@topspin.com> <20041217214432.07b7b21e.davem@davemloft.net> <1103484675.1050.158.camel@jzny.localdomain> <52fz21ncgh.fsf@topspin.com> |
| Reply-to: | hadi@xxxxxxxxxx |
| Sender: | netdev-bounce@xxxxxxxxxxx |
On Sun, 2004-12-19 at 17:35, Roland Dreier wrote: > jamal> How about releasing the qlock only when the LLTX transmit > jamal> lock is grabbed? That should bring it to par with what it > jamal> was originally. > > This seems a little risky. I can't point to a specific deadlock but > it doesn't seem right on general principles to unlock in a different > order than you nested the locks when acquiring them -- if I understand > correctly, you're suggesting lock(queue_lock), lock(tx_lock), > unlock(queue_lock), unlock(tx_lock). There is no deadlock. Thats exactly how things work. Try the patches i posted. cheers, jamal |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: [patch 4/10] s390: network driver., jamal |
|---|---|
| Next by Date: | Re: LLTX and netif_stop_queue, Roland Dreier |
| Previous by Thread: | Re: LLTX and netif_stop_queue, Roland Dreier |
| Next by Thread: | Re: LLTX and netif_stop_queue, Roland Dreier |
| Indexes: | [Date] [Thread] [Top] [All Lists] |