From: Herbert Xu <[EMAIL PROTECTED]> Date: Sun, 16 Apr 2006 21:18:31 +1000
> Great eyes! Yes that bug seems to have been around forever. I'll > look over the patch tomorrow as right now I'm still on west-coast > time :) Let me save you some time, later in the thread you'll find out that this whole thing is a dead end. The reason is that all SKBs are unshared when we receive them into the TCP stack for sk->sk_receive_queue. (this is done by ip_rcv()). This means every __kfree_skb() call would happen in the context of the TCP stack with the socket locked, so no concurrency issues wrt. sk_forward_alloc as I originally thought. In fact, this is what makes using __kfree_skb() explicitly legal in the first place. If skb->users could be non-zero, from tcpdump etc., then we'd be required to call kfree_skb() in the TCP code that frees up used packets on the receive queue. But all is not lost, this is an important datapoint. We've audited the receive side accesses to sk_forward_alloc and it all looks good. And again, as you mention, we go back again to TSO being the deciding factor in triggering this or not. So it nearly has to be a send side issue that can only trigger with TSO enabled, and my next planned chore is to audit the TSO splitting during ACK processing. We may be doing something stupid there. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
