From: sashiko-bot@kernel.org
To: "Geliang Tang" <geliang@kernel.org>
Cc: mptcp@lists.linux.dev
Subject: Re: [PATCH mptcp-next v5 5/7] mptcp: defer read_sock cleanup to mptcp_worker
Date: Sat, 22 Aug 2026 03:36:54 +0000 [thread overview]
Message-ID: <20260822033655.35ED61F000E9@smtp.kernel.org> (raw)
In-Reply-To: <7aedfbb77f40f047f2c7724c481220a8322b7ad2.1787368526.git.tanggeliang@kylinos.cn>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Inverted order of `mptcp_cleanup_rbuf()` and `mptcp_rcv_space_adjust()` causes delayed receive window expansion.
--
--- Patch [5]: [PATCH mptcp-next v5 5/7] mptcp: defer read_sock cleanup to mptcp_worker ---
commit 7c6cfb1e14c2505035ad95612907c5f1c34d25e5
Author: Paolo Abeni <pabeni@redhat.com>
mptcp: defer read_sock cleanup to mptcp_worker
This commit defers sk->sk_data_ready(sk) cleanup tasks to the MPTCP worker
using a new MPTCP_WORK_READ_COMPLETE flag. This avoids locking recursions and
context-related issues when MPTCP carries TLS.
> diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
> index 6006193388f12..648eba89278f6 100644
> --- a/net/mptcp/protocol.c
> +++ b/net/mptcp/protocol.c
> @@ -3133,6 +3133,15 @@ static void mptcp_backlog_purge(struct sock *sk)
> sk_mem_reclaim(sk);
> }
>
> +static void mptcp_read_complete(struct sock *sk)
> +{
> + struct mptcp_sock *msk = mptcp_sk(sk);
> +
> + mptcp_cleanup_rbuf(msk, msk->read_copied);
> + mptcp_rcv_space_adjust(msk, msk->read_copied);
[Severity: Medium]
Does the inverted order of these function calls delay receive window expansion?
Before this patch in __mptcp_read_sock(), mptcp_rcv_space_adjust() was called
before mptcp_cleanup_rbuf(). Because mptcp_cleanup_rbuf() evaluates the
current socket receive buffer capacity to decide whether to send a window
update ACK, calling mptcp_rcv_space_adjust() afterward means the buffer
capacity is expanded after the cleanup check has already run.
Could this cause the ACK sent to advertise the old, smaller window size,
delaying the expanded window advertisement until the next cycle?
> + msk->read_copied = 0;
> +}
> +
> static void mptcp_do_fastclose(struct sock *sk)
[ ... ]
> @@ -4641,11 +4651,14 @@ static int __mptcp_read_sock(struct sock *sk, read_descriptor_t *desc,
> if (noack)
> goto out;
>
> - mptcp_rcv_space_adjust(msk, copied);
> -
> + /* The backlog flushing is only needed when some data is actually
> + * moved and will take place in the workers's release callback.
> + */
> if (copied > 0) {
> mptcp_recv_skb(sk, &offset);
> - mptcp_cleanup_rbuf(msk, copied);
> + msk->read_copied += copied;
> + set_bit(MPTCP_WORK_READ_COMPLETE, &msk->flags);
> + mptcp_schedule_work(sk);
> }
> out:
> return copied;
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1787368526.git.tanggeliang@kylinos.cn?part=5
next prev parent reply other threads:[~2026-08-22 3:36 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-22 3:19 [PATCH mptcp-next v5 0/7] Reduce the differences between TCP and MPTCP for TLS usage Geliang Tang
2026-08-22 3:19 ` [PATCH mptcp-next v5 1/7] mptcp: drop the mptcp_ooo_try_coalesce() helper Geliang Tang
2026-08-22 3:19 ` [PATCH mptcp-next v5 2/7] mptcp: drop the cant_coalesce CB field Geliang Tang
2026-08-22 3:19 ` [PATCH mptcp-next v5 3/7] mptcp: remove CB offset field Geliang Tang
2026-08-22 3:36 ` sashiko-bot
2026-08-22 3:19 ` [PATCH mptcp-next v5 4/7] mptcp: sync mptcp skb cb layout with tcp one Geliang Tang
2026-08-22 3:19 ` [PATCH mptcp-next v5 5/7] mptcp: defer read_sock cleanup to mptcp_worker Geliang Tang
2026-08-22 3:36 ` sashiko-bot [this message]
2026-08-22 3:19 ` [PATCH mptcp-next v5 6/7] mptcp: track app-limited state in mptcp_sendmsg Geliang Tang
2026-08-22 3:28 ` sashiko-bot
2026-08-22 3:19 ` [PATCH mptcp-next v5 7/7] selftests: mptcp: sockopt: check app_limited Geliang Tang
2026-08-22 4:33 ` [PATCH mptcp-next v5 0/7] Reduce the differences between TCP and MPTCP for TLS usage MPTCP CI
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=20260822033655.35ED61F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=geliang@kernel.org \
--cc=mptcp@lists.linux.dev \
--cc=sashiko-reviews@lists.linux.dev \
/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.