dev.c -- dev_queue_xmit-- Is the comment misleading or is it a bug??

[Kumar, Sharath]

Hi, (Please mark a cc to my id  in your reply as I am not subscribed to this list Thanks in advance :-))

I am attaching the snippet for dev_queue_xmit code in net/core/dev.c 

The issue I am trying to point out here is about calling this function from  an interrupt context.
(The comment clearly says that I am right in doing so)

So this function has to be re-entrant if it can be called from an interrupt which means 
q->enqueue() also needs to be re-entrant.

The enqueue function by default is mapped to  pfifo_fast_enqueue  (net/sched/sch_generic.c)
unfortunately the code in this function updates the transmit queue and qdisc->q.qlen
without disabling interrupts. 

So If I call dev_queue_xmit from a non-interrupt context and if I  have an interrupt which again makes
a call to dev_queue_xmit(on the same device), then my transmit queue may be left in inconsistent state  :-(

Either the comment is misleading or I am missing something here.

/**
 *	dev_queue_xmit - transmit a buffer
 *	@skb: buffer to transmit
 *
 *	Queue a buffer for transmission to a network device. The caller must
 *	have set the device and priority and built the buffer before calling
 *	this function. The function can be called from an interrupt.
 *
 *	A negative errno code is returned on a failure. A success does not
 *	guarantee the frame will be transmitted as it may be dropped due
 *	to congestion or traffic shaping.
 */

int dev_queue_xmit(struct sk_buff *skb)
{
		..
	..
	/* Grab device queue */
	spin_lock_bh(&dev->queue_lock);
	q = dev->qdisc;
	if (q->enqueue) {
		rc = q->enqueue(skb, q);


Regards.
-Sharath.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/