| To: | hadi@xxxxxxxxxx |
|---|---|
| Subject: | Re: LLTX and netif_stop_queue |
| From: | Roland Dreier <roland@xxxxxxxxxxx> |
| Date: | Sun, 19 Dec 2004 14:35:26 -0800 |
| Cc: | "David S. Miller" <davem@xxxxxxxxxxxxx>, netdev@xxxxxxxxxxx, openib-general@xxxxxxxxxx |
| In-reply-to: | <1103484675.1050.158.camel@jzny.localdomain> (jamal's message of "19 Dec 2004 14:31:15 -0500") |
| References: | <52llbwoaej.fsf@topspin.com> <20041217214432.07b7b21e.davem@davemloft.net> <1103484675.1050.158.camel@jzny.localdomain> |
| Sender: | netdev-bounce@xxxxxxxxxxx |
| User-agent: | Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) |
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).
Thanks,
Roland
|
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: [patch 4/10] s390: network driver., Tommy Christensen |
|---|---|
| Next by Date: | Re: [patch 4/10] s390: network driver., Jeff Garzik |
| Previous by Thread: | Re: LLTX and netif_stop_queue, Jamal Hadi Salim |
| Next by Thread: | Re: LLTX and netif_stop_queue, jamal |
| Indexes: | [Date] [Thread] [Top] [All Lists] |