TCP output handling bug ?

TCP output handling bug ?

[Alan Cox]

tcp_send_syn_data:

        TCP_SKB_CB(data)->tcp_flags &= ~TCPHDR_SYN;
        TCP_SKB_CB(data)->tcp_flags = (TCPHDR_ACK|TCPHDR_PSH);

the reporter has a point 8)


https://bugzilla.kernel.org/show_bug.cgi?id=82101

Re: TCP output handling bug ?

[Stephen Hemminger]

On Thu, 21 Aug 2014 19:02:08 +0100
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> 
> tcp_send_syn_data:
> 
>         TCP_SKB_CB(data)->tcp_flags &= ~TCPHDR_SYN;
>         TCP_SKB_CB(data)->tcp_flags = (TCPHDR_ACK|TCPHDR_PSH);
> 
> the reporter has a point 8)
> 
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=82101
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

I wonder if covertity or smatch could be smart enough to catch this kind of bug?

Re: TCP output handling bug ?

[Dave Jones]

On Thu, Aug 21, 2014 at 05:24:45PM -0700, Stephen Hemminger wrote:
 > On Thu, 21 Aug 2014 19:02:08 +0100
 > Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
 > 
 > > 
 > > tcp_send_syn_data:
 > > 
 > >         TCP_SKB_CB(data)->tcp_flags &= ~TCPHDR_SYN;
 > >         TCP_SKB_CB(data)->tcp_flags = (TCPHDR_ACK|TCPHDR_PSH);
 > > 
 > > the reporter has a point 8)
 > > 
 > > https://bugzilla.kernel.org/show_bug.cgi?id=82101
 > 
 > I wonder if covertity or smatch could be smart enough to catch this kind of bug?

For coverity: it should be, but isn't :)
I've pointed them at the bugzilla, maybe they can add a check in a
future update.

I bet this isn't the only instance of a bug like this left in the tree.
We've definitely had similar cases before.

	Dave

Re: TCP output handling bug ?

[Eric Dumazet]

On Thu, 2014-08-21 at 22:13 -0400, Dave Jones wrote:
> On Thu, Aug 21, 2014 at 05:24:45PM -0700, Stephen Hemminger wrote:
>  > On Thu, 21 Aug 2014 19:02:08 +0100
>  > Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>  > 
>  > > 
>  > > tcp_send_syn_data:
>  > > 
>  > >         TCP_SKB_CB(data)->tcp_flags &= ~TCPHDR_SYN;
>  > >         TCP_SKB_CB(data)->tcp_flags = (TCPHDR_ACK|TCPHDR_PSH);
>  > > 
>  > > the reporter has a point 8)
>  > > 
>  > > https://bugzilla.kernel.org/show_bug.cgi?id=82101
>  > 
>  > I wonder if covertity or smatch could be smart enough to catch this kind of bug?
> 
> For coverity: it should be, but isn't :)
> I've pointed them at the bugzilla, maybe they can add a check in a
> future update.
> 
> I bet this isn't the only instance of a bug like this left in the tree.
> We've definitely had similar cases before.
> 
> 	Dave


There is no bug here as a matter of fact.

You can simply remove the first line, as it is useless.


-	TCP_SKB_CB(data)->tcp_flags &= ~TCPHDR_SYN;


At the end of the day, data segment has ACK and PSH flags only.

Re: TCP output handling bug ?

[David Miller]

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 22 Aug 2014 06:56:30 -0700

CC:'ing Yuchung Cheng

> On Thu, 2014-08-21 at 22:13 -0400, Dave Jones wrote:
>> On Thu, Aug 21, 2014 at 05:24:45PM -0700, Stephen Hemminger wrote:
>>  > On Thu, 21 Aug 2014 19:02:08 +0100
>>  > Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>>  > 
>>  > > 
>>  > > tcp_send_syn_data:
>>  > > 
>>  > >         TCP_SKB_CB(data)->tcp_flags &= ~TCPHDR_SYN;
>>  > >         TCP_SKB_CB(data)->tcp_flags = (TCPHDR_ACK|TCPHDR_PSH);
>>  > > 
>>  > > the reporter has a point 8)
>>  > > 
>>  > > https://bugzilla.kernel.org/show_bug.cgi?id=82101
>>  > 
>>  > I wonder if covertity or smatch could be smart enough to catch this kind of bug?
>> 
>> For coverity: it should be, but isn't :)
>> I've pointed them at the bugzilla, maybe they can add a check in a
>> future update.
>> 
>> I bet this isn't the only instance of a bug like this left in the tree.
>> We've definitely had similar cases before.
>> 
>> 	Dave
> 
> There is no bug here as a matter of fact.
> 
> You can simply remove the first line, as it is useless.
> 
> -	TCP_SKB_CB(data)->tcp_flags &= ~TCPHDR_SYN;
> 
> At the end of the day, data segment has ACK and PSH flags only.

What about ECE/CWR?

Re: TCP output handling bug ?

[Yuchung Cheng]

On Fri, Aug 22, 2014 at 10:41 AM, David Miller <davem@davemloft.net> wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Fri, 22 Aug 2014 06:56:30 -0700
>
> CC:'ing Yuchung Cheng
>
>> On Thu, 2014-08-21 at 22:13 -0400, Dave Jones wrote:
>>> On Thu, Aug 21, 2014 at 05:24:45PM -0700, Stephen Hemminger wrote:
>>>  > On Thu, 21 Aug 2014 19:02:08 +0100
>>>  > Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>>>  >
>>>  > >
>>>  > > tcp_send_syn_data:
>>>  > >
>>>  > >         TCP_SKB_CB(data)->tcp_flags &= ~TCPHDR_SYN;
>>>  > >         TCP_SKB_CB(data)->tcp_flags = (TCPHDR_ACK|TCPHDR_PSH);
>>>  > >
>>>  > > the reporter has a point 8)
>>>  > >
>>>  > > https://bugzilla.kernel.org/show_bug.cgi?id=82101
>>>  >
>>>  > I wonder if covertity or smatch could be smart enough to catch this kind of bug?
>>>
>>> For coverity: it should be, but isn't :)
>>> I've pointed them at the bugzilla, maybe they can add a check in a
>>> future update.
>>>
>>> I bet this isn't the only instance of a bug like this left in the tree.
>>> We've definitely had similar cases before.
>>>
>>>      Dave
>>
>> There is no bug here as a matter of fact.
>>
>> You can simply remove the first line, as it is useless.
>>
>> -     TCP_SKB_CB(data)->tcp_flags &= ~TCPHDR_SYN;
>>
>> At the end of the day, data segment has ACK and PSH flags only.
>
> What about ECE/CWR?

sorry for the late response. my original intention was
TCP_SKB_CB(data)->tcp_flags &= ~TCPHDR_SYN;
TCP_SKB_CB(data)->tcp_flags |= (TCPHDR_ACK|TCPHDR_PSH);

so that we can keep other flags intact b/c in the future we may have
xmas tree packet :-)
I will send a patch soon.

Re: TCP output handling bug ?

[Eric Dumazet]

On Fri, 2014-08-22 at 10:41 -0700, David Miller wrote:

> What about ECE/CWR?

TCP fastopen begins its life with a fresh socket.

We received no packet from the peer yet for this flow that we are
building.