Messages in this thread |  | | Date | Tue, 03 Oct 2000 17:27:52 +0300 | From | Petko Manolov <> | Subject | Re: Request for net guru help: waitqueue oops |
| |
Hans Grobler wrote: > > On Tue, 3 Oct 2000, Petko Manolov wrote: > > > It seems you're trying to sleep without process context (most likely in > > net_tx_action). It would be more clear if you send that part of the > > code. > > Since I don't explictly sleep anywhere, I'm not sure which code fragment > would be useful... (net_tx_action is part of the networking layers). Which > network functions can sleep (netif_rx, netif_stop_queue, netif_wake_queue, > ...) ?
None of these can sleep. netif_*_queue routines are quite simple. They are all atomic so there is no need to protect them with locks.
> After reading the softnet HOWTO, and some of the network drivers, I > was unsure about the netif_stop_queue and netif_wake_queue functions. The > howto indicated that these two should be protected from concurrent > execution by a private lock. Not all the drivers seem to do this. In my > case (although I'm running UP at the moment), I've used a driver global > spinlock, for example: > > spinlock_t driver_lock = SPIN_LOCK_UNLOCKED; > > int scc72_hard_xmit (struct sk_buff *skb, struct net_device *dev) > { > unsigned long flags; > > /* ... */ > > spin_lock_irqsave (&driver_lock, flags); > netif_stop_queue (dev); > spin_unlock_irqrestore (&driver_lock, flags); > > /* ... */ > } > > /* Example timer callback, to wake the queue */ > void scc72_interframewait (unsigned long channel) > { > unsigned long flags; > struct scc72_channel *scc = (struct scc72_channel *) channel; > > /* ... */ > > spin_lock_irqsave (&driver_lock, flags); > > /* ... */ > > if (netif_queue_stopped (scc->dev)) > netif_wake_queue (scc->dev); > > spin_unlock_irqrestore (&driver_lock, flags); > }
It is not clear from the example above if it is needed to lock in the timer routine and what is locked inside. Anyway be careful about locking regions shared between interrupts/bottom halves and user context as this happens often.
best, Petkan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |