same skb is added to the msg's skb_list multiple times in ss_tcp_process_skb()

[vdmit11]

The ss_tcp_process_skb()/ss_tcp_process_proto_skb() iterate over sk_buff's fragments and make several upcalls for each fragment.

There are two problems:

1. put_skb_to_msg() is called for each fragment. The function enqueues the given skb to the msg's skb_list, so the same skb is actually added to the list multiple times (for each fragment of the skb).
2. On SS_POSTPONE, the postpone_skb() is called after put_skb_to_msg(). Both functions add the skb to the msg's skb_list, so the same skb is added twice when the message is postponed.

[keshonok]

Eventually, ss_skb_queue_tail() is called in all cases, and it has protection from a double insertion. If an SKB in on the list already, then it's not put there again.

This sort of design might be questionable, but that's a totally different topic. The bug does not exist as described.

[krizhanovsky]

This is poor design of put_skb_to_msg(), must be fixed. There is no sense to call the hook many times just to see that the skb is already in the list.

[keshonok]

It appears that the fix is not complete. When the message is postponed - and that the usual course of action as an skb is processed in chunks - tfw_connection_postpone_skb() attempts to add the skb to the message's skb_list again. Always.

[krizhanovsky]

Ok, please do the fix.

[keshonok]

The rest of this issue is moved to #80.