Messages in this thread | | | Date | Thu, 10 Nov 2005 11:42:16 +0800 | From | Tony <> | Subject | Re: Debug: sleeping function called from invalid context at mm/slab.c:2126 |
| |
Parag Warudkar wrote: >>I'm writing a net_device driver. I want to send a packet when the timer >>is out. I get the following warning. It seems that I should not call >>alloc_skb. Can anyone tell me how to get rid of this? Thanks in advance. >> > > > You are calling alloc_skb which in turn calls kmem_cache_alloc in interrupt context where things can't sleep and kmem_cache_alloc can sleep. The reason for this is that you are passing GFP_KERNEL to alloc_skb. Try passing GFP_ATOMIC instead. > > Other alternative is to may be use a precreated pool of skbs - may be this can be done in driver init function or any other safe context. But I don't know how much feasible that is in your situation. > > HTH > Parag > > > Thanks a lot. Another question.
My interface is a virtual interface which represent a radio connected to the host using ethernet NIC. I designed my own L2 protocol on top of 802.3, which must be used, since the radio and the host are connected by ethernet.
Now, my radio_hard_header will only add my L2 header, and my radio_hard_start_xmit will do (simplified): 1) ajust the headroom space hh_len = LL_RESERVED_SPACE(bdev); if (unlikely(skb_headroom(skb) < hh_len && bdev->hard_header)) { struct sk_buff *skb2;
skb2 = skb_realloc_headroom(skb, LL_RESERVED_SPACE(dev)); if (skb2 == NULL) { stats->tx_dropped++; dev_kfree_skb(skb); return 0; } if (skb->sk) skb_set_owner_w(skb2, skb->sk); dev_kfree_skb(skb); skb = skb2; }
2) call eth0->hard_header 3) skb->dev = eth0 return dev_queue_xmit()
The problem is when system try to retransmit the packet, I add another ethernet header mistakenly.
I have two question: 1) I do not modify the skb passed to hard_start_xmit if skb_realloc_headroom is executed. only in this case the retransmission runs well. Is my understanding right? 2) Should I do this way or add the ethernet header in my radio_hard_header? If I choose the later, the problem will be how should I handle it when eth_hard_header return a negative number, when ARP is needed.
Thx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |