On Tue, 17 Nov 1998, Olaf Meyer wrote:
> void
> print_wl(const rtnode_t *node, int mode, const char *fmt, ...)
> {
> static char buf[256];
You never overrun this, right? Also, could this code ever be re-entered?
If so, it would be wiser to use an auto buffer, or disable interrupts
around critical sections that use the buffer (i.e. pretty much
the whole thing) using save_flags()/cli()/restore_flags().
> void
> wl_transmit_skb(struct sk_buff *skb)
> {
> if (!skb) {
> printk("wl *** wl_transmit_skb(): skb NULL pointer\n");
> return;
> }
>
> // spinlock until device is ready
> while(skb->dev->tbusy)
> ;
This looks suspicious. If you call this code from the interrupt for that same
device, it could deadlock, since you need to handle the interrupt in order to
unbusy the device, and the interrupts are serialized.
> // this transmits the buffer to the WaveLAN card
> // and dumps it onto the network
> wv_packet_write(skb->dev, skb->data, skb->len);
Is wv_packet_write safe to call from here? This function is normally called
from the driver's xmit function, which is in a bottom-half context, not in a
raw interrupt. Bottom-half functions tend to be written in a non-reentrant
fashion.
> dev_kfree_skb(skb, FREE_WRITE);
Don't use dev_kfree_skb for something that you allocated with alloc_skb.
The matching mate for dev_kfree_skb is dev_alloc_skb. Although it's
no big deal here since the only difference between the two allocs is that
the dev_ one allocates an extra 16 bytes for header space, and always
uses GFP_ATOMIC. You could just use kfree_skb here.
You should set skb->free = 1 after allocating the buffer, otherwise it won't
be freed properly by kfree_skb(). (At least in 2.0 kernels).
My advice: try running with your debugging function acting as a thin wrapper
for printk. Change your sprintf buffer to auto, and disable the network
dumping. See if the problem is still there.
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
