All Virtuozzo development lists (kernel + QEMU)
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.