From: we...@ucloud.cn
Date: Mon, 29 Jun 2020 17:16:17 +0800
> From: wenxu <we...@ucloud.cn>
>
> The fragment packets do defrag in tcf_ct_handle_fragments
> will clear the skb->cb which make the qdisc_skb_cb clear
> too and set the pkt_len to 0. The bytes always 0 when dump
> the filter. And it also update the pkt_len after all the
> fragments finish the defrag to one packet and make the
> following action counter correct.
>
> filter protocol ip pref 2 flower chain 0 handle 0x2
> eth_type ipv4
> dst_ip 1.1.1.1
> ip_flags frag/firstfrag
> skip_hw
> not_in_hw
> action order 1: ct zone 1 nat pipe
> index 2 ref 1 bind 1 installed 11 sec used 11 sec
> Action statistics:
> Sent 0 bytes 11 pkt (dropped 0, overlimits 0 requeues 0)
> backlog 0b 0p requeues 0
> cookie e04106c2ac41769b278edaa9b5309960
>
> Fixes: b57dc7c13ea9 ("net/sched: Introduce action ct")
> Signed-off-by: wenxu <we...@ucloud.cn>
This is a much larger and serious problem IMHO. And this fix is
not sufficient.
Nothing can clobber the qdisc_skb_cb like this in these packet flows
otherwise we will have serious crashes and problems. Some packet
schedulers store pointers in the qdisc CB private area, for example.
We need to somehow elide the CB clear when packets are defragmented by
connection tracking.
