Re: [PATCH mptcp-next v5 1/6] mptcp: replace lock_sock_fast with lock_sock in sockopt

[gang.yan@linux.dev]

May 22, 2026 at 5:12 PM, "Gang Yan" <gang.yan@linux.dev mailto:gang.yan@linux.dev?to=%22Gang%20Yan%22%20%3Cgang.yan%40linux.dev%3E > wrote:

Hi Matt, Paolo:

I have a question about this patch.

My plan is to take patches 2~6 as a new series that focuses on fixing
MPTCP setsockopt issues under BPF context in the next version.

This patch 1 is separate — it addresses a potential sleeping-in-atomic
problem in the normal (non-BPF) setsockopt call path, similar to 
b5c52908d5("mptcp: fix scheduling with atomic in timestamp sockopt").

Could you please take a look and let me know if this patch is needed?

If it is, I'd appreciate it if you could review it separately and
potentially apply it directly, or I can spin a new version based on
your feedback.

If it's not required, I'll just drop it.

Thanks,
Gang 
> 
> From: Gang Yan <yangang@kylinos.cn>
> 
> Replace lock_sock_fast()/unlock_sock_fast() with lock_sock()/
> release_sock() in the MPTCP sockopt handlers to avoid accidentally
> introducing sleeping operations inside the lock_sock_fast() critical
> section.
> 
> This is consistent with how other sockopt handlers in the Net code
> already use lock_sock()/release_sock().
> 
> Signed-off-by: Gang Yan <yangang@kylinos.cn>
> ---
>  net/mptcp/sockopt.c | 18 ++++++++----------
>  1 file changed, 8 insertions(+), 10 deletions(-)
> 
> diff --git a/net/mptcp/sockopt.c b/net/mptcp/sockopt.c
> index 1cf608e7357b..35a74e44a500 100644
> --- a/net/mptcp/sockopt.c
> +++ b/net/mptcp/sockopt.c
> @@ -77,8 +77,8 @@ static void mptcp_sol_socket_sync_intval(struct mptcp_sock *msk, int optname, in
>  
>  mptcp_for_each_subflow(msk, subflow) {
>  struct sock *ssk = mptcp_subflow_tcp_sock(subflow);
> - bool slow = lock_sock_fast(ssk);
>  
> + lock_sock(ssk);
>  switch (optname) {
>  case SO_DEBUG:
>  sock_valbool_flag(ssk, SOCK_DBG, !!val);
> @@ -114,7 +114,7 @@ static void mptcp_sol_socket_sync_intval(struct mptcp_sock *msk, int optname, in
>  }
>  
>  subflow->setsockopt_seq = msk->setsockopt_seq;
> - unlock_sock_fast(ssk, slow);
> + release_sock(ssk);
>  }
>  
>  release_sock(sk);
> @@ -270,8 +270,8 @@ static int mptcp_setsockopt_sol_socket_linger(struct mptcp_sock *msk, sockptr_t
>  sockopt_seq_inc(msk);
>  mptcp_for_each_subflow(msk, subflow) {
>  struct sock *ssk = mptcp_subflow_tcp_sock(subflow);
> - bool slow = lock_sock_fast(ssk);
>  
> + lock_sock(ssk);
>  if (!ling.l_onoff) {
>  sock_reset_flag(ssk, SOCK_LINGER);
>  } else {
> @@ -280,7 +280,7 @@ static int mptcp_setsockopt_sol_socket_linger(struct mptcp_sock *msk, sockptr_t
>  }
>  
>  subflow->setsockopt_seq = msk->setsockopt_seq;
> - unlock_sock_fast(ssk, slow);
> + release_sock(ssk);
>  }
>  
>  release_sock(sk);
> @@ -749,11 +749,10 @@ static int mptcp_setsockopt_v4_set_tos(struct mptcp_sock *msk, int optname,
>  val = READ_ONCE(inet_sk(sk)->tos);
>  mptcp_for_each_subflow(msk, subflow) {
>  struct sock *ssk = mptcp_subflow_tcp_sock(subflow);
> - bool slow;
>  
> - slow = lock_sock_fast(ssk);
> + lock_sock(ssk);
>  __ip_sock_set_tos(ssk, val);
> - unlock_sock_fast(ssk, slow);
> + release_sock(ssk);
>  }
>  release_sock(sk);
>  
> @@ -1647,12 +1646,11 @@ int mptcp_set_rcvlowat(struct sock *sk, int val)
>  WRITE_ONCE(sk->sk_rcvbuf, space);
>  mptcp_for_each_subflow(mptcp_sk(sk), subflow) {
>  struct sock *ssk = mptcp_subflow_tcp_sock(subflow);
> - bool slow;
>  
> - slow = lock_sock_fast(ssk);
> + lock_sock(ssk);
>  WRITE_ONCE(ssk->sk_rcvbuf, space);
>  WRITE_ONCE(tcp_sk(ssk)->window_clamp, val);
> - unlock_sock_fast(ssk, slow);
> + release_sock(ssk);
>  }
>  return 0;
>  }
> 
> -- 
> 2.43.0
>