Thread (17 messages) flat view 17 messages, 5 authors, 2008-08-01

Re: Kernel WARNING: at net/core/dev.c:1330 __netif_schedule+0x2c/0x98()

From: Jarek Poplawski <hidden>
Date: 2008-07-25 20:00:43
Also in: linux-wireless, lkml

Possibly related (same subject, not in this thread)

On Fri, Jul 25, 2008 at 09:36:15PM +0200, Johannes Berg wrote:
On Fri, 2008-07-25 at 21:34 +0200, Jarek Poplawski wrote:
quoted
quoted
Umm, of course it cannot, because then we'd have to take the mutex in
the TX path, which we cannot. We cannot have another lock in the TX
path, what's so hard to understand about? We need to be able to lock all
queues to lock out multiple tx paths at once in some (really) slow paths
but not have any extra lock overhead for the tx path, especially not a
single lock.
But this mutex doesn't have to be mutex. And it's not for the tx path,
only for "service" just like netif_tx_lock(). The fast path needs only
queue->tx_lock.
No, we need to be able to lock out multiple TX paths at once.
IMHO, it can do the same. We could e.g. insert a locked spinlock into
this noop_tx_handler(), to give everyone some waiting.

Jarek P.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help