All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Geliang Tang" <geliang@kernel.org>
Cc: mptcp@lists.linux.dev
Subject: Re: [PATCH mptcp-next v5 6/7] mptcp: track app-limited state in mptcp_sendmsg
Date: Sat, 22 Aug 2026 03:28:04 +0000	[thread overview]
Message-ID: <20260822032804.F030A1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <456a51551b99654bd84efa9565bdad7412a419cf.1787368526.git.tanggeliang@kylinos.cn>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Lockdep recursive locking warning due to missing nested lock annotation in mptcp_sock_rate_check_app_limited().
--

--- Patch [6]: [PATCH mptcp-next v5 6/7] mptcp: track app-limited state in mptcp_sendmsg ---
commit 991a38880507b6d69cccc4a195bee5ef68452bf9
Author: Geliang Tang <tanggeliang@kylinos.cn>

mptcp: track app-limited state in mptcp_sendmsg

This commit splits the TCP app-limited rate checking logic into a helper
that takes a tcp_sock, and adds an MPTCP-specific helper to apply this
rate checking to each subflow individually during sendmsg.

[ ... ]

> diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
> index 648eba89278f6..735cd39846462 100644
> --- a/net/mptcp/protocol.c
> +++ b/net/mptcp/protocol.c
> @@ -2045,6 +2045,21 @@ static void mptcp_rps_record_subflows(const struct mptcp_sock *msk)
>  	}
>  }
>  
> +static void mptcp_sock_rate_check_app_limited(struct sock *sk)
> +{
> +	struct mptcp_sock *msk = mptcp_sk(sk);
> +	struct mptcp_subflow_context *subflow;
> +
> +	mptcp_for_each_subflow(msk, subflow) {
> +		struct sock *ssk = mptcp_subflow_tcp_sock(subflow);
> +		bool slow;
> +
> +		slow = lock_sock_fast(ssk);

[Severity: Medium]
Does acquiring the subflow socket lock here trigger a lockdep recursive
locking warning?

mptcp_sendmsg() acquires the parent MPTCP socket lock using lock_sock(sk),
and then calls mptcp_sock_rate_check_app_limited(sk) right after. This
function iterates over the connection subflows and acquires each subflow's
socket lock via lock_sock_fast(ssk).

Because both locks share the same lock class, lockdep might flag this
nested acquisition as a possible recursive lock splat, which can disable
further lock debugging.

Is it possible to use lock_sock_fast_nested(ssk) or a similar nested lock
annotation here to suppress the false positive?

> +		tcp_sock_rate_check_app_limited(tcp_sk(ssk));
> +		unlock_sock_fast(ssk, slow);
> +	}
> +}
> +
>  static int mptcp_sendmsg(struct sock *sk, struct msghdr *msg, size_t len)
>  {
>  	struct mptcp_sock *msk = mptcp_sk(sk);

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1787368526.git.tanggeliang@kylinos.cn?part=6

  reply	other threads:[~2026-08-22  3:28 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
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 [this message]
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=20260822032804.F030A1F000E9@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.