Linux kernel -stable discussions
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: Santosh Sakore <quic_ssakore@quicinc.com>
Cc: fastrpc.upstream@qti.qualcomm.com, quic_ekangupt@quicinc.com,
	quic_bkumar@quicinc.com, stable@vger.kernel.org
Subject: Re: [PATCH v1 01/41] mptcp: fully established after ADD_ADDR echo on MPJ
Date: Sun, 11 Aug 2024 14:04:42 +0200	[thread overview]
Message-ID: <2024081119-impish-vixen-475f@gregkh> (raw)
In-Reply-To: <20240809101849.1814-2-quic_ssakore@quicinc.com>

On Fri, Aug 09, 2024 at 03:48:09PM +0530, Santosh Sakore wrote:
> From: "Matthieu Baerts (NGI0)" <matttbe@kernel.org>
> 
> Before this patch, receiving an ADD_ADDR echo on the just connected
> MP_JOIN subflow -- initiator side, after the MP_JOIN 3WHS -- was
> resulting in an MP_RESET. That's because only ACKs with a DSS or
> ADD_ADDRs without the echo bit were allowed.
> 
> Not allowing the ADD_ADDR echo after an MP_CAPABLE 3WHS makes sense, as
> we are not supposed to send an ADD_ADDR before because it requires to be
> in full established mode first. For the MP_JOIN 3WHS, that's different:
> the ADD_ADDR can be sent on a previous subflow, and the ADD_ADDR echo
> can be received on the recently created one. The other peer will already
> be in fully established, so it is allowed to send that.
> 
> We can then relax the conditions here to accept the ADD_ADDR echo for
> MPJ subflows.
> 
> Fixes: 67b12f792d5e ("mptcp: full fully established support after ADD_ADDR")
> Cc: stable@vger.kernel.org
> Reviewed-by: Mat Martineau <martineau@kernel.org>
> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
> Link: https://patch.msgid.link/20240731-upstream-net-20240731-mptcp-endp-subflow-signal-v1-1-c8a9b036493b@kernel.org
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
> ---
>  net/mptcp/options.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

Any reason you are resending this to us again?

Please fix your scripts...

greg k-h

  reply	other threads:[~2024-08-11 12:04 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20240809101849.1814-1-quic_ssakore@quicinc.com>
2024-08-09 10:18 ` [PATCH v1 01/41] mptcp: fully established after ADD_ADDR echo on MPJ Santosh Sakore
2024-08-11 12:04   ` Greg KH [this message]
2024-08-09 10:18 ` [PATCH v1 02/41] mptcp: pm: deny endp with signal + subflow + port Santosh Sakore
2024-08-09 10:18 ` [PATCH v1 04/41] mptcp: pm: don't try to create sf if alloc failed Santosh Sakore
2024-08-09 10:18 ` [PATCH v1 05/41] mptcp: pm: do not ignore 'subflow' if 'signal' flag is also set Santosh Sakore
2024-08-09 10:18 ` [PATCH v1 32/41] idpf: fix memleak in vport interrupt configuration Santosh Sakore

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2024081119-impish-vixen-475f@gregkh \
    --to=greg@kroah.com \
    --cc=fastrpc.upstream@qti.qualcomm.com \
    --cc=quic_bkumar@quicinc.com \
    --cc=quic_ekangupt@quicinc.com \
    --cc=quic_ssakore@quicinc.com \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox