Re: [RFC PATCH mptcp-next v7 08/11] Fix unxpctd val of subflow->map_seq(dscrd packet)

[Matthieu Baerts <matthieu.baerts@tessares.net>]

Hi Paolo, Dmytro,

On 19/09/2022 13:27, Paolo Abeni wrote:
> On Sun, 2022-09-18 at 00:28 +0200, Dmytro Shytyi wrote:
>> Fix unexpected value of subflow->map_seq (discarded and after
>> retransmitted 2nd packet)
>>
>> Signed-off-by: Dmytro Shytyi <dmytro@shytyi.net>
>> ---
>>  net/mptcp/subflow.c | 6 ++++--
>>  1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c
>> index c7d49fb6e7bd..075c61d1d37f 100644
>> --- a/net/mptcp/subflow.c
>> +++ b/net/mptcp/subflow.c
>> @@ -1077,8 +1077,10 @@ static enum mapping_status get_mapping_status(struct sock *ssk,
>>  		/* will validate the next map after consuming the current one */
>>  		goto validate_csum;
>>  	}
>> -
>> -	subflow->map_seq = map_seq;
>> +	if (msk->is_mptfo)
>> +		subflow->map_seq = READ_ONCE(msk->ack_seq);
>> +	else
>> +		subflow->map_seq = map_seq;
>>  	subflow->map_subflow_seq = mpext->subflow_seq;
>>  	subflow->map_data_len = data_len;
>>  	subflow->map_valid = 1;
> 
> 
> This is likely not needed, if you build a special dss mapping at
> incoming option processing time.

Also for this, Benjamin had another approach by delaying MPTCP data_ack
calculation, see from patch 5/10 from [1]. It might be good to discuss
about that at the next weekly meeting.

Cheers,
Matt

[1]
https://lore.kernel.org/mptcp/20220908133829.3410092-1-benjamin.hesmans@tessares.net/T/
-- 
Tessares | Belgium | Hybrid Access Solutions
www.tessares.net