[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <89404b82-71b8-c94d-1e0b-11e3755da0b3@ucloud.cn>
Date: Thu, 2 Jul 2020 17:17:47 +0800
From: wenxu <wenxu@...oud.cn>
To: David Miller <davem@...emloft.net>
Cc: netdev@...r.kernel.org
Subject: Re: [PATCH net 1/2] net/sched: act_ct: fix restore the qdisc_skb_cb
after defrag
On 7/2/2020 6:21 AM, David Miller wrote:
> From: wenxu@...oud.cn
> Date: Mon, 29 Jun 2020 17:16:17 +0800
>
>> From: wenxu <wenxu@...oud.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 <wenxu@...oud.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.
Why store all the cb private and restore it can't total fix this?
>
> We need to somehow elide the CB clear when packets are defragmented by
> connection tracking.
you means add new function like ip_defrag_nocb for qdisc cb case?
>
Powered by blists - more mailing lists