From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 381A13E63AC for ; Mon, 27 Jul 2026 09:07:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785143269; cv=none; b=icJ9+o8ERK/kZplxw/XDsi3YYWGxeaUuM0U06C3WO6YrI4mDPLDPCxGYqz1FWNmPMq67nB8T9jppHu2pk1OiFx/aNLFkgB+XGps2xLsKebG75jjRL0UcCoXgpHCfgldByT4VyJmWkRNPzR5CsM4RuppLMTNW+tyvmNsXpEy6ZmQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785143269; c=relaxed/simple; bh=LHTwQzb1gcagsKYDCbh4Uu3tI3NgNUQJ4rSjFOX1KyA=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=DXDBlbJ8MS4RHSmbdV7V7C0IYGAcT91yv05CKXtcvxiDpf4HTj7HgDehTU9KpME1YL2ol8YRbT+tqgmmmmG6cry05n8T+HKSpouJL5wSPSC6iBHAsCM7OqevNyU6AWYK7OEN+4wzla/lpymIHlV6YdwSuPE/exP+0KEO55kFfhs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=O78KpHQl; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=VjlsMZDC; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="O78KpHQl"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="VjlsMZDC" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1785143267; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=rApJhbpK/b0CVV5ov/9vIdRIrElFvcSvZqbKQTS4MB8=; b=O78KpHQlDPeWp/ksmOnpkgT6ODOAN+3DSZT3T5f/zq92qOXse5YnKVyZzIWPceUW5UV9kU unUpOdxVqC9KsubOY4AWhKj7+ODSi/xcNFepk8LMHKNk6HPu+wTV5GJmVwBE+0l5EwBO1M yH01Cto8YWNhR1fPj5JASSsx/Ux/cGM= Received: from mail-ej1-f71.google.com (mail-ej1-f71.google.com [209.85.218.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-345-RDZFx0EYNTCfpr7ogip3uA-1; Mon, 27 Jul 2026 05:07:45 -0400 X-MC-Unique: RDZFx0EYNTCfpr7ogip3uA-1 X-Mimecast-MFC-AGG-ID: RDZFx0EYNTCfpr7ogip3uA_1785143265 Received: by mail-ej1-f71.google.com with SMTP id a640c23a62f3a-c16740eb587so192517966b.1 for ; Mon, 27 Jul 2026 02:07:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1785143264; x=1785748064; darn=vger.kernel.org; h=content-transfer-encoding:content-type:in-reply-to:content-language :from:references:cc:to:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to:content-type; bh=rApJhbpK/b0CVV5ov/9vIdRIrElFvcSvZqbKQTS4MB8=; b=VjlsMZDCcJ06n83HYuTDlHPEpDthZUQp33Y8iijioaWy4pIFR75Q9lVGI+Dk/LoF2h M+KhyEG20GgmKYTp8FqdFINC5SpYaJYZNrqk3k9Xb3oMg87YuJl2oy6mKGnqBC1MwIL0 DsxM6BGvkWHP/SDFp55TSSNO0tdKWHHpVLOliMdpZPJBYRzMkyMKApmOYkTB5ScIgtrh PNb4tK879NMUu+3Zf+aDhMnkKJ2TXs+QKRZ8nETBcd8ZjRbWsuVQI7TB0O0jYC0YiLcM 5RZ5jwIINeXnnXrrrSFxTg56ixPYBTKUYm7ZYv3CVxjcOLKXOmtRUByIi7VHac62WB/r se0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785143264; x=1785748064; h=content-transfer-encoding:content-type:in-reply-to:content-language :from:references:cc:to:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=rApJhbpK/b0CVV5ov/9vIdRIrElFvcSvZqbKQTS4MB8=; b=gHY+QOCCdN7ho61aB1COHw7UiHSqecBAip5iNb/ww5NSIHCejel/E8ej73ysYHUPaf sJOEWy0I5dvr+7lYMDBq7VAseK1hRco99JJO+oB6gPyVIhfPqvGm8o5BbUsDRwSJCQUC XoGJBsDHLJ6NYUPGuWk9ADW+KY9FMVTAX1nANMC+jfTsJfU8VrBDkQ1bzC1zd91RUiT9 FNSRCqryTT5rRT84kd7hx5kMkUsrIeJFZpsYH479V7Lel0BESxH1dOYwXyvap5ChF17t G9V98GPC/ybcj5zSFsa82n608oaznuw0K9OxNBz2LdvCugQKFUmL4+d3s4r5qvR30hPL ANGA== X-Forwarded-Encrypted: i=1; AHgh+RpIT+/rNBQeI24pCgphVkpFeejKH9x8tpIVHnBwLztfijQwlTjDxzxLIZ/BWzI0EZcOLvFwX4BDPn76FD8=@vger.kernel.org X-Gm-Message-State: AOJu0YxxJEyqSxajFhvPFTK3GG/VrfvESA4RLVF1DpjNnnfXM39kq0Im KuvTdmrEpW/ab/2rE22hT1fWRc4AfQP/UuLLQroqyMcHx9U3GKQdosxjI5dbr99mCtGop11RJTC CZTHcpPZM3RKlImTAzpBQsLwTX68v8rsyMmkycIsU4BMbxRAPIEfG4YHdcUM4ljWEvFIElD2hwQ == X-Gm-Gg: AR+sD117dhh1yrHOkQd8E4DeP/UoxsT/+vht6hxulWkblffmmNVcnBgp7SVe72v7UH+ GrfRFHTuTV4ddjGEpCALoam61/r1JUPqMxnpWdGPBlskxVvHMh8uzBW86r5nLVUPDuVRDDYvpDP dP6tCoWaDI/WUTNSq8RrceHEtCzy6BSXmaJsBKD7DVTCG1pAxCcYW62WRtoTLBka8u7a4ibgCg2 isVEB90FON9bYhixTWSUDu+S4bZ5RFWt3wlT/Ky98bYTJSHjz1RvP1cJwiGLy7O0FjJ95VY5OHp WFYpskpQb9LBtK/ls6iBzkBWR5CJHx57hsYOjdMibdeSy3ccPMu8lqvUE1RG70cPCOcjimmlH8X rp0RTTWqb495yzuPGQ6WoCj0A2UZa8ugdB/y+GS3bhzsp/8ioK0SQIkoP6P1VE9L5Ju5VOPL3FM PEPQ== X-Received: by 2002:a17:906:9f85:b0:c15:a1e8:c141 with SMTP id a640c23a62f3a-c1f1f032c7amr381694566b.30.1785143264451; Mon, 27 Jul 2026 02:07:44 -0700 (PDT) X-Received: by 2002:a17:906:9f85:b0:c15:a1e8:c141 with SMTP id a640c23a62f3a-c1f1f032c7amr381693566b.30.1785143263925; Mon, 27 Jul 2026 02:07:43 -0700 (PDT) Received: from ?IPV6:2a0d:3344:5521:6b10:58fd:68f:7756:389d? ([2a0d:3344:5521:6b10:58fd:68f:7756:389d]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c1c32a78260sm601879866b.6.2026.07.27.02.07.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 27 Jul 2026 02:07:43 -0700 (PDT) Message-ID: <90370236-b773-4419-b42e-eab6a3a9385b@redhat.com> Date: Mon, 27 Jul 2026 11:07:41 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH net-next 3/5] mptcp: explicitly drop over memory limits To: "Matthieu Baerts (NGI0)" , Mat Martineau , Geliang Tang , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Simon Horman Cc: netdev@vger.kernel.org, mptcp@lists.linux.dev, linux-kernel@vger.kernel.org References: <20260724-net-next-mptcp-oooq-pruning-v1-0-5dd4dec63a54@kernel.org> <20260724-net-next-mptcp-oooq-pruning-v1-3-5dd4dec63a54@kernel.org> From: Paolo Abeni Content-Language: en-US In-Reply-To: <20260724-net-next-mptcp-oooq-pruning-v1-3-5dd4dec63a54@kernel.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 7/24/26 4:02 PM, Matthieu Baerts (NGI0) wrote: > From: Paolo Abeni > > Currently the enforcement of the rcvbuf constraint is implemented > when moving the skbs into the msk receive or OoO queue, keeping the > incoming skbs in the subflow queue when over limits. > > Under significant memory pressure the above can cause permanent data > transfer stalls, as the skb needed to make forward progress can be > stuck in a subflow queue. > > Over memory limits, drop the incoming skb, relying on MPTCP-level > retransmissions. > > Note that fallback socket must perform the limit before the skb reaches > the subflow-level queue, as dropping an in-sequence already acked skb > would break the stream. > > This is not a complete fix for the stall issue, as the drop strategy > needs refinements that will come in the next patches. > > Signed-off-by: Paolo Abeni > Reviewed-by: Matthieu Baerts (NGI0) > Signed-off-by: Matthieu Baerts (NGI0) > --- > net/mptcp/mib.c | 2 ++ > net/mptcp/mib.h | 2 ++ > net/mptcp/options.c | 28 +++++++++++++++++++++++++--- > net/mptcp/protocol.c | 31 +++++++++++++++++++++++-------- > 4 files changed, 52 insertions(+), 11 deletions(-) > > diff --git a/net/mptcp/mib.c b/net/mptcp/mib.c > index f23fda0c55a7..ef65e2df709f 100644 > --- a/net/mptcp/mib.c > +++ b/net/mptcp/mib.c > @@ -85,6 +85,8 @@ static const struct snmp_mib mptcp_snmp_list[] = { > SNMP_MIB_ITEM("SimultConnectFallback", MPTCP_MIB_SIMULTCONNFALLBACK), > SNMP_MIB_ITEM("FallbackFailed", MPTCP_MIB_FALLBACKFAILED), > SNMP_MIB_ITEM("WinProbe", MPTCP_MIB_WINPROBE), > + SNMP_MIB_ITEM("BacklogDrop", MPTCP_MIB_BACKLOGDROP), > + SNMP_MIB_ITEM("RcvPruned", MPTCP_MIB_RCVPRUNED), > }; > > /* mptcp_mib_alloc - allocate percpu mib counters > diff --git a/net/mptcp/mib.h b/net/mptcp/mib.h > index 812218b5ed2b..c84eb853d499 100644 > --- a/net/mptcp/mib.h > +++ b/net/mptcp/mib.h > @@ -88,6 +88,8 @@ enum linux_mptcp_mib_field { > MPTCP_MIB_SIMULTCONNFALLBACK, /* Simultaneous connect */ > MPTCP_MIB_FALLBACKFAILED, /* Can't fallback due to msk status */ > MPTCP_MIB_WINPROBE, /* MPTCP-level zero window probe */ > + MPTCP_MIB_BACKLOGDROP, /* Backlog over memory limit */ > + MPTCP_MIB_RCVPRUNED, /* Dropped due to memory constrains */ > __MPTCP_MIB_MAX > }; > > diff --git a/net/mptcp/options.c b/net/mptcp/options.c > index c664023d37ba..7b954ef78672 100644 > --- a/net/mptcp/options.c > +++ b/net/mptcp/options.c > @@ -1127,8 +1127,30 @@ 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); > + u64 mem = sk_rmem_alloc_get(sk); > + > + mem += READ_ONCE(msk->backlog_len); > + if (likely(mem <= 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); > + return true; > +} > + > +/* Return false when the caller must drop the packet, i.e. in case of error, > + * subflow has been reset, or over memory limits. > */ > bool mptcp_incoming_options(struct sock *sk, struct sk_buff *skb) > { > @@ -1154,7 +1176,7 @@ bool mptcp_incoming_options(struct sock *sk, struct sk_buff *skb) > > __mptcp_data_acked(subflow->conn); > mptcp_data_unlock(subflow->conn); > - return true; > + return !mptcp_over_limit(subflow->conn, sk, skb); > } > > mptcp_get_options(skb, &mp_opt); > diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c > index 72b1fa3ca71c..5f7d8340a3d9 100644 > --- a/net/mptcp/protocol.c > +++ b/net/mptcp/protocol.c > @@ -381,6 +381,16 @@ static bool __mptcp_move_skb(struct sock *sk, struct sk_buff *skb) > > mptcp_borrow_fwdmem(sk, skb); > > + /* Can't drop packets for fallback socket this late, or the stream > + * will break. > + */ > + if (unlikely(sk_rmem_alloc_get(sk) > READ_ONCE(sk->sk_rcvbuf)) && > + !__mptcp_check_fallback(msk)) { > + MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_RCVPRUNED); > + mptcp_drop(sk, skb); Here sashiko fears a possible forward-allocated memory leak. That is sort of antinomy, as forward-allocated memory will be used for the next skb(s) and excess fwd allocated memory will be still freed after the next skb(s) processing or at sk close time. There is no real permanent leak. We could release additionally allocated fwd memory in the error path as a follow-up. /P