>>> I can see this working if you have a special type of skb that >>> indicates that the data might be concurrently written and have all the >>> normal skb APIs (including, especially, anything that clones it) make >>> a copy first. >> >> Support for cloned skbs is required for TCP, both at tcp_transmit_skb >> and segmentation offload. Patch 4 especially adds reference counting >> of shared pages across clones and other sk_buff operations like >> pskb_expand_head. This still allows for deep copy (skb_copy_ubufs) >> on clones in specific datapaths like the above. > > Does this mean that a user program that does a zerocopy send can cause > a retransmitted segment to contain different data than the original > segment? If so, is that okay? That is possible, indeed. The bytestream at the receiver is then likely undefined. Though integrity of the tcp receive stack should not be affected. A valid question is whether the stack should protect against such users. The pattern is reminiscent of evasion attacks. In the limited case, privileged users already can generate this data pattern, of course. -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
