Re: [PATCH mptcp-next RFC 2/3] mptcp: reject MP_JOIN earlier

On 8/17/26 11:49 AM, Matthieu Baerts wrote:
> On 17/08/2026 09:27, Paolo Abeni wrote:
>> On 8/14/26 8:31 PM, Matthieu Baerts (NGI0) wrote:
>>> @@ -91,12 +92,22 @@ static struct mptcp_sock *subflow_token_join_request(struct request_sock *req)
>>>  	msk = mptcp_token_get_sock(sock_net(req_to_sk(req)), subflow_req->token);
>>>  	if (!msk) {
>>>  		SUBFLOW_REQ_INC_STATS(req, MPTCP_MIB_JOINNOTOKEN);
>>> +		*reason = MPTCP_RST_EMPTCP;
>>> +		return NULL;
>>> +	}
>>> +
>>> +	/* Stop it early if the subflow cannot be accepted */
>>> +	if (!mptcp_can_accept_new_subflow(msk)) {
>>
>> Side note: the above is inherently racy, the consistency safeguard is
>> given by the fallback check at finish_join time.
> 
> Just to be sure: even if it is racy, is it OK to use it here but
> continuing having the safe check at finish_join time?
> 
> In other words, having such a comment is enough?
> 
>   /* Stop it early if the subflow cannot be accepted.
>    * This check is inherently racy, the consistency safeguard is
>    * given by the fallback check at finish_join time.
>    */

I think so.

>> Minor nit: I'm not sure this check belongs here or in
>> subflow_check_req(). The latter option would avoid the additional
>> argument and possibly produce a smaller diff (and smaller code).
> 
> After re-looking at this code yesterday, I agree with you. Also, I think
> subflow_token_join_request() should only return the msk, and not
> changing anything else from subflow_req.
Makes sense.

Somewhat related: to avoid subflow_check_req() growing too much, it
would possibly make sense move the final mp_join related bits in a
specific helper, and have just:

	} else if (opt_mp_join && listener->request_mptcp)
		return subflow_mpj_check_req(req, sk_listener);

/P