Re: [PATCH mptcp-next RFC 2/3] mptcp: reject MP_JOIN earlier
Matthieu Baerts <[email protected]>
| Newsgroups | dev.linux.lists.mptcp |
|---|---|
| Organization | NGI0 Core |
| Message-ID | <[email protected]> |
Hi Paolo,
Thank you for having looked at this!
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.
*/
> 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.
Cheers,
Matt
--
Sponsored by the NGI0 Core fund.