Re: [PATCH mptcp-next 02/12] mptcp: explicitly drop over memory limits

[Paolo Abeni <pabeni@redhat.com>]

On 5/9/26 9:48 AM, Paolo Abeni wrote:
> diff --git a/net/mptcp/options.c b/net/mptcp/options.c
> index 4cc583fdc7a9..19c0bc92f04e 100644
> --- a/net/mptcp/options.c
> +++ b/net/mptcp/options.c
> @@ -1158,8 +1158,29 @@ static bool add_addr_hmac_valid(struct mptcp_sock *msk,
>  	return hmac == mp_opt->ahmac;
>  }
>  
> -/* Return false in case of error (or subflow has been reset),
> - * else return true.
> +static bool mptcp_over_limit(struct sock *sk, struct sock *ssk,
> +			     const struct sk_buff *skb)
> +{
> +	struct mptcp_sock *msk = mptcp_sk(sk);
> +
> +	if (likely(sk_rmem_alloc_get(sk) + READ_ONCE(msk->backlog_len) <=
> +		   READ_ONCE(sk->sk_rcvbuf)))
> +		return false;
> +
> +	/* Avoid silently dropping pure acks, fin or zero win probes. */
> +	if (TCP_SKB_CB(skb)->seq == TCP_SKB_CB(skb)->end_seq ||
> +	    TCP_SKB_CB(skb)->tcp_flags & TCPHDR_FIN ||
> +	    !after(TCP_SKB_CB(skb)->end_seq, tcp_sk(ssk)->rcv_nxt))
> +		return false;
> +
> +	/* Dropped due to memory constraints, schedule an ack. */
> +	inet_csk(ssk)->icsk_ack.pending |= ICSK_ACK_NOMEM | ICSK_ACK_NOW;
> +	inet_csk_schedule_ack(ssk);

Sashiko says:

---
Does returning true here cause a permanent data transfer stall?
When mptcp_over_limit() decides to drop a packet, it schedules an ACK and
returns true, which in turn makes mptcp_incoming_options() return false.
When this occurs in the TCP fast path or early in tcp_v4_rcv(), returning
false instructs the TCP stack to jump immediately to the discard label. This
bypasses the standard tcp_ack_snd_check() calls located at the end of the
receive path.
Since inet_csk_schedule_ack() only sets the ICSK_ACK_SCHED pending flag and
does not arm the delayed ACK timer, the scheduled ACK is never dispatched.
The sender will eventually timeout, retransmit the identical packet, hit
this exact same memory limit, and be dropped again without an ACK.
---
That is a bit of an allucination: mptcp subflow can't hit fastpath, and
the other referenced mptcp_incoming_options() calls happens only for
states that prevent the other end from sending more data: the mentioned
stall is not possible

/P