Set proper tcp_gso_segs for skb with TLS TAG.

[EvgeniiMekhanik]

Previosly we don't set tcp_gso_segs for skb with new added TLS TAG, because we assume that it will be set during tso,tcp}_fragment() from tcp_write_xmit. It is not correct, because skb with new added TLS TAG can be already produced during one of previous call of tso,tcp}_fragment(). In this case this skb has already set tcp_gso_segs. Later in the loop in tcp_write_xmit tcp_init_tso_segs skips such skbs if tcp_gso_segs > 1, but mss is same. Limit will be also greater then mss, because if tcp_gso_segs > 1, limit is recalculated. In this case we never set proper tcp_gso_segs (with taking into account new added TLS TAG), that leads to kernel BUG during call tcp_shifted_skb.
This BUG was hardly reproduced, because:

• it is not a usual case when TLS TAG is added to the skb, which was produced during call tso,tcp}_fragment().
• tcp_shifted_skb is called very rarely from tcp_shift_skb_data. This two conditions were reproduced only on mtu 80 under heavy load.

[const-t]

LGTM.

Seems it can happens only on loopback interface, am I right? Also I would like to ask, maybe we can move tcp_set_skb_tso_segs(skb, mss_now); from tcp_tfw_sk_write_xmit() to tfw_tls_encrypt() to do this in one place? Looks like this is only for cases where we have only one skb to encrypt, for other cases we do tcp_set_skb_tso_segs() in tfw_tls_encrypt().

[EvgeniiMekhanik]

Not only for loopback interface. According to our private discussion tcp_write_xmit->tcp_event_new_data_sent add
skb to the tcp_rtx_queue. Then when ack received tcp_sacktag_walk is called and we iterate over all skbs in tcp_rtx_queue (skb_rbtree_walk_from(skb))

[EvgeniiMekhanik]

No this is a case when tail_skb != skb and there is no one skb for encryption, because if there is only one skb for encryption we call tcp_set_skb_tso_segs for it in tcp_tfw_sk_write_xmit