Hi Liping,
On Fri, Sep 2, 2016 at 12:50 PM, Liping Zhang <zlpnobody@xxxxxxxxx> wrote:
> Hi Feng,
> 2016-09-02 9:48 GMT+08:00 <fgao@xxxxxxxxxx>:
>> From: Gao Feng <fgao@xxxxxxxxxx>
>> @@ -171,6 +176,11 @@ int nf_ct_seq_adjust(struct sk_buff *skb,
>> struct nf_ct_seqadj *this_way, *other_way;
>> int res;
>>
>> + if (unlikely(!seqadj)) {
>
> IPS_SEQ_ADJUST_BIT will be tested before we call nf_ct_seq_adjust(),
> so I think seqadj
> will never be NULL here.
Thanks. I didn't check IPS_SEQ_ADJUST_BIT flag.
>
>> + WARN_ONCE(1, "Missing nfct_seqadj_ext_add() setup call\n");
>> + return 0;
>> + }
>> +
>> this_way = &seqadj->seq[dir];
>> other_way = &seqadj->seq[!dir];
>>
>> @@ -218,8 +228,10 @@ s32 nf_ct_seq_offset(const struct nf_conn *ct,
>> struct nf_conn_seqadj *seqadj = nfct_seqadj(ct);
>> struct nf_ct_seqadj *this_way;
>>
>> - if (!seqadj)
>> + if (unlikely(!seqadj)) {
>> + WARN_ONCE(1, "Missing nfct_seqadj_ext_add() setup call\n");
>
> But in nf_ct_seq_offset, seqadj is likely to be NULL, see the function
> call path:
> tcp_packet->tcp_in_window->nf_ct_seq_offset, so WARN_ONCE seems unnecessary.
>
>> return 0;
>> + }
Get it. It could be NULL.
Then only nf_ct_seqadj_init is necessary to check seqadj.
I will update this patch.
Regards
Feng
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
