From: "David S. Miller" <[EMAIL PROTECTED]> Date: Fri, 14 Apr 2006 20:59:27 -0700 (PDT)
> Any ideas? Come to think of it, __sk_stream_mem_reclaim() looks > really racey even as-is. I came up with one more possible approach, it goes something like this: 1) Get rid of the skb->destructor callback for TCP receive data. 2) Adjust sk_rmem_alloc and sk_forward_alloc explicitly when we add packets to sk_receive_queue/out_of_order_queue, and when we unlink them from sk_receive_queue and __kfree_skb() them up. I think this would work and get rid of the unlocked accesses to sk_forward_alloc. And it would do so without adding new overheads (the other two ideas did, by adding locks or turning sk_forward_alloc into an atomic_t). The implementation needs a bit of thinking in order to not mess up all the nice abstractions Arnaldo has created for stream sockets and the interfaces we share between TCP and DCCP. But actually DCCP needs this fix too, since it also uses sk_forward_alloc, so building the solution into the shared interfaces is desirable. Too bad this will take a little bit of time to implement, I really want to be able to cook up a much simpler test patch that the people who can reproduce the BUG() can try out. - 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
