OpenVZ / Virtuozzo kernel development (devel@openvz.org)
 help / color / mirror / Atom feed
From: no-reply@sashiko.virtuozzo.com
To: Eva Kurchatova <eva.kurchatova@virtuozzo.com>, khorenko@virtuozzo.com
Cc: devel@openvz.org
Subject: Re: [Devel] [PATCH hci-8.1 1/8] ms/mptcp: fix retransmission loop when csum is enabled
Date: Fri, 6 Nov 2026 03:07:24 +0000	[thread overview]
Message-ID: <010701a1aed34772-28c94ba5-5fa6-417e-9598-ebdd1dab980d-000000@eu-central-1.amazonses.com> (raw)
In-Reply-To: <20261106030306.16014-2-eva.kurchatova@virtuozzo.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] mptcp: __mptcp_retrans() advances snd_nxt without updating bytes_sent
--

commit 4d64a3ef806956ed9e7612432b9f24e9542dcd61
Author: Paolo Abeni <pabeni@redhat.com>

ms/mptcp: fix retransmission loop when csum is enabled

This commit raises msk->snd_nxt in __mptcp_retrans() when a retransmission
with csum enabled sends data past the old dfrag->already_sent. The goal is
to stop incoming ACKs from being dropped, which caused an endless
retransmission loop.

Link: https://patch.msgid.link/20260602-net-mptcp-misc-fixes-7-1-rc7-v2-2-856831229976@kernel.org

> diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
> --- a/net/mptcp/protocol.c
> +++ b/net/mptcp/protocol.c

[ ... ]

> @@ -2666,6 +2666,10 @@ static void __mptcp_retrans(struct sock *sk)
>  	msk->bytes_retrans += len;
>  	dfrag->already_sent = max(dfrag->already_sent, len);
>  
> +	/* With csum enabled retransmission can send new data. */
> +	if (after64(dfrag->already_sent + dfrag->data_seq, msk->snd_nxt))
> +		WRITE_ONCE(msk->snd_nxt, dfrag->already_sent + dfrag->data_seq);
> +

[Severity: Medium]
Should msk->bytes_sent be updated here as well?

When csum is enabled, __mptcp_retrans() sets info.limit to dfrag->data_len,
so the loop can send bytes beyond the old dfrag->already_sent.  Those bytes
are new data.

This hunk advances msk->snd_nxt for them, but it does not do the matching
accounting that mptcp_update_post_push() does on the normal push path:

mptcp_update_post_push() {
    ...
		msk->bytes_sent += snd_nxt_new - msk->snd_nxt;
		WRITE_ONCE(msk->snd_nxt, snd_nxt_new);
    ...
}

As a result, msk->bytes_sent, which is reported through MPTCP_INFO,
under-reports the new data sent from __mptcp_retrans().

The earlier msk->bytes_retrans += len in the same function also counts those
new bytes as retransmitted, so bytes_retrans appears to over-report.

Is msk->snd_burst also expected to be reduced for this new data, as
mptcp_update_post_push() does on the normal push path?

>  reset_timer:
>  	mptcp_check_and_set_pending(sk);
>

-- 
Sashiko AI review · https://sashiko.vzint.dev/#/patchset/20261106030306.16014-1-eva.kurchatova@virtuozzo.com?part=1

_______________________________________________
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel

  reply	other threads:[~2026-11-06  3:08 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-06  3:02 [Devel] [PATCH hci-8.1 0/8] ms/mptcp: stability fixes Eva Kurchatova
2026-11-06  3:02 ` [Devel] [PATCH hci-8.1 1/8] ms/mptcp: fix retransmission loop when csum is enabled Eva Kurchatova
2026-11-06  3:07   ` no-reply [this message]
2026-11-06  3:02 ` [Devel] [PATCH hci-8.1 2/8] ms/mptcp: move the retrans loop to a separate helper Eva Kurchatova
2026-11-06  3:06   ` no-reply
2026-11-06  3:02 ` [Devel] [PATCH hci-8.1 3/8] ms/mptcp: move the stale logic out of retrans scheduler Eva Kurchatova
2026-11-06  3:07   ` no-reply
2026-11-06  3:02 ` [Devel] [PATCH hci-8.1 4/8] ms/mptcp: let the retrans scheduler do its job Eva Kurchatova
2026-11-06  3:10   ` no-reply
2026-11-06  3:02 ` [Devel] [PATCH hci-8.1 5/8] ms/mptcp: explicitly drop over memory limits Eva Kurchatova
2026-11-06  3:10   ` no-reply
2026-11-06  3:02 ` [Devel] [PATCH hci-8.1 6/8] ms/mptcp: implemented OoO queue pruning Eva Kurchatova
2026-11-06  3:11   ` no-reply
2026-11-06  3:02 ` [Devel] [PATCH hci-8.1 7/8] ms/mptcp: being below memory limit is a likely() condition Eva Kurchatova
2026-11-06  3:10   ` no-reply
2026-11-06  3:02 ` [Devel] [PATCH hci-8.1 8/8] ms/mptcp: avoid pruning for OoW data Eva Kurchatova
2026-11-06  3:11   ` no-reply

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=010701a1aed34772-28c94ba5-5fa6-417e-9598-ebdd1dab980d-000000@eu-central-1.amazonses.com \
    --to=no-reply@sashiko.virtuozzo.com \
    --cc=devel@openvz.org \
    --cc=eva.kurchatova@virtuozzo.com \
    --cc=khorenko@virtuozzo.com \
    /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