[You may think that this is an amazing coincidence that the
buffer is removed from the tcp_ack chain just at the time
that it is being transmitted. I suspect that the RTT estimator
is managing to estimate the RTT correctly, and so the ack code
is retransmitting the packet at the same time that the ack is
being received -- hence the collision.]
Question: Why doesn't the tcp_ack code do anything with the
locked bit? Should it really be calling dev_kfree_skb instead?
My feeling is that if the buffer is locked at the time that
tcp_ack wants to dequeue it, then it should not dequeue it, and
it should not free it. Does this seem right?
Philip
p.s. I modified the code from tcp_ack to make it more likely
to fail by adding a 100usec delay between enabling interrupts
and doing the checks.
cli();
if (skb->next)
skb_unlink(skb);
sti();
/*start tmp*/
if (skb->list)
printk(KERN_WARNING "skb (%p) back on list (%p)\n", skb,
skb->list);
udelay(100);
if (skb->list)
printk(KERN_WARNING "delay(100): skb (%p) back on list
(%p)\n", skb, skb->list);
/*end tmp*/
kfree_skb(skb, FREE_WRITE); /* write. */
-- Philip Gladstone +1 617 487 7700 Raptor Systems, Waltham, MA http://www.raptor.com/