Re: [PATCH mptcp-next v5 6/7] mptcp: track app-limited state in mptcp_sendmsg

[email protected]
Newsgroups dev.linux.lists.mptcp
Message-ID <[email protected]>
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 <[email protected]>

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/[email protected]?part=6
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.