From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============3077483598839210702==" MIME-Version: 1.0 From: David Miller To: mptcp at lists.01.org Subject: [MPTCP] Re: [PATCH net] mptcp: Initialize map_seq upon subflow establishment Date: Tue, 12 May 2020 12:09:11 -0700 Message-ID: <20200512.120911.2258216308785425487.davem@davemloft.net> In-Reply-To: 6b0594845f7787b9bc82c845321e23b6bc3bca38.camel@redhat.com X-Status: X-Keywords: X-UID: 4374 --===============3077483598839210702== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable From: Paolo Abeni Date: Mon, 11 May 2020 19:35:21 +0200 > On Mon, 2020-05-11 at 09:24 -0700, Christoph Paasch wrote: >> When the other MPTCP-peer uses 32-bit data-sequence numbers, we rely on >> map_seq to indicate how to expand to a 64-bit data-sequence number in >> expand_seq() when receiving data. >> = >> For new subflows, this field is not initialized, thus results in an >> "invalid" mapping being discarded. >> = >> Fix this by initializing map_seq upon subflow establishment time. >> = >> Fixes: f296234c98a8 ("mptcp: Add handling of incoming MP_JOIN requests") >> Signed-off-by: Christoph Paasch ... > Reviewed-by: Paolo Abeni Applied, thanks. --===============3077483598839210702==-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B268DC2D0F7 for ; Tue, 12 May 2020 19:09:18 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9DB2A2492B for ; Tue, 12 May 2020 19:09:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730987AbgELTJS (ORCPT ); Tue, 12 May 2020 15:09:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53488 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725950AbgELTJR (ORCPT ); Tue, 12 May 2020 15:09:17 -0400 Received: from shards.monkeyblade.net (shards.monkeyblade.net [IPv6:2620:137:e000::1:9]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 20042C061A0C for ; Tue, 12 May 2020 12:09:17 -0700 (PDT) Received: from localhost (unknown [IPv6:2601:601:9f00:477:9e51:a893:b0fe:602a]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: davem-davemloft) by shards.monkeyblade.net (Postfix) with ESMTPSA id 660131282BA1A; Tue, 12 May 2020 12:09:14 -0700 (PDT) Date: Tue, 12 May 2020 12:09:11 -0700 (PDT) Message-Id: <20200512.120911.2258216308785425487.davem@davemloft.net> To: pabeni@redhat.com Cc: cpaasch@apple.com, kuba@kernel.org, netdev@vger.kernel.org, mptcp@lists.01.org Subject: Re: [MPTCP] [PATCH net] mptcp: Initialize map_seq upon subflow establishment From: David Miller In-Reply-To: <6b0594845f7787b9bc82c845321e23b6bc3bca38.camel@redhat.com> References: <20200511162442.78382-1-cpaasch@apple.com> <6b0594845f7787b9bc82c845321e23b6bc3bca38.camel@redhat.com> X-Mailer: Mew version 6.8 on Emacs 26.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Tue, 12 May 2020 12:09:14 -0700 (PDT) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org From: Paolo Abeni Date: Mon, 11 May 2020 19:35:21 +0200 > On Mon, 2020-05-11 at 09:24 -0700, Christoph Paasch wrote: >> When the other MPTCP-peer uses 32-bit data-sequence numbers, we rely on >> map_seq to indicate how to expand to a 64-bit data-sequence number in >> expand_seq() when receiving data. >> >> For new subflows, this field is not initialized, thus results in an >> "invalid" mapping being discarded. >> >> Fix this by initializing map_seq upon subflow establishment time. >> >> Fixes: f296234c98a8 ("mptcp: Add handling of incoming MP_JOIN requests") >> Signed-off-by: Christoph Paasch ... > Reviewed-by: Paolo Abeni Applied, thanks.