On Wed, Jun 13, 2018 at 7:50 AM, Eric Dumazet wrote:
>
>
> On 06/12/2018 02:41 PM, Frank van der Linden wrote:
>> commit 079096f103fa ("tcp/dccp: install syn_recv requests into ehash
>> table") introduced an optimization for the handling of child sockets
>> created for a new TCP connection.
>>
>>
Ok, patch v3 sent.
It was rightly pointed out to me that I shouldn't commit the mortal sin of top
posting - but bear with me guys, I'll dig up my 25-year old .muttrc :-)
Frank
On 6/12/18, 3:03 PM, "Eric Dumazet" wrote:
On 06/12/2018 02:53 PM, van der Linden, Frank wrote:
> T
Sure, fair enough. I was assuming there might be a reason of why tcp_filter was
always done after the data (not pseudo header) checksum. If there isn't (and
obviously the the possible MD5 checks are done before it too), then that's
definitely the right thing to do.
I'll resend. Though if you ha
On 06/12/2018 02:53 PM, van der Linden, Frank wrote:
> The convention seems to be to call tcp_checksum_complete after tcp_filter has
> a chance to deal with the packet. I wanted to preserve that.
>
> If that is not a concern, then I agree that this is a far better way to go.
>
> Frank
Given
The convention seems to be to call tcp_checksum_complete after tcp_filter has a
chance to deal with the packet. I wanted to preserve that.
If that is not a concern, then I agree that this is a far better way to go.
Frank
On 6/12/18, 2:50 PM, "Eric Dumazet" wrote:
On 06/12/2018
On 06/12/2018 02:41 PM, Frank van der Linden wrote:
> commit 079096f103fa ("tcp/dccp: install syn_recv requests into ehash
> table") introduced an optimization for the handling of child sockets
> created for a new TCP connection.
>
> But this optimization passes any data associated with the las
commit 079096f103fa ("tcp/dccp: install syn_recv requests into ehash
table") introduced an optimization for the handling of child sockets
created for a new TCP connection.
But this optimization passes any data associated with the last ACK of the
connection handshake up the stack without verifying
