[PATCH mptcp-net 0/2] mptcp: replace lock_sock_fast with sleepable lock

[PATCH mptcp-net 0/2] mptcp: replace lock_sock_fast with sleepable lock

[Gang Yan]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=y, Size: 1404 bytes --]

From: Gang Yan <yangang@kylinos.cn>

Hi Matt,

I make some progress about the issue sashiko mentioned in:
https://sashiko.dev/#/patchset/20260420093343.16443-1-gang.yan@linux.dev

The problem does exist,though the trigger conditions seem quite strict.

asdasda shjaksdjh askjd hjklajsdhfj klasjd aklshd kljasldkj akjlsd klklk

I’ve checked how TCP and core socket handle similar sockopt operations,
and found they almost always use sockopt_lock_sock() in 
setsockopt/getsockopt paths — a variant of lock_sock() that also
considers BPF cases.

I think we can align MPTCP with a similar approach to fix this properly.
This will come as a two-patch series, split for easier review and
backporting to stable branches:

    - 0001: The first patch replaces lock_sock_fast() with lock_sock()
      to fix the potential sleeping issue in timestamp and timestamping
      sockopt handlers.

    - 0002: The second patch converts all lock operations in MPTCP
      setsockopt / getsockopt to use sockopt_lock_sock(), preventing
      similar issues from being accidentally introduced in the future.
      And I think it should use 'mptcp-next' tag.

Gang Yan (2):
  mptcp: fix scheduling with atomic in timestamp sockopt
  mptcp: use sockopt_lock(release)_sock in sockopt

 net/mptcp/sockopt.c | 121 ++++++++++++++++++++++----------------------
 1 file changed, 60 insertions(+), 61 deletions(-)

-- 
2.43.0

[PATCH mptcp-net 1/2] mptcp: fix scheduling with atomic in timestamp sockopt

[Gang Yan]

From: Gang Yan <yangang@kylinos.cn>

Using lock_sock_fast() (atomic context) around sock_set_timestamp()
and sock_set_timestamping() is unsafe, as both helpers can sleep.

Replace lock_sock_fast() with sleepable lock_sock()/release_sock()
to avoid scheduling while atomic panic.

Assisted-by: Sashiko
Fixes: 9061f24bf82e ("mptcp: sockopt: propagate timestamp request to subflows")
Fixes: 6c9a0a0f2333 ("mptcp: setsockopt: convert to mptcp_setsockopt_sol_socket_timestamping()")
Signed-off-by: Gang Yan <yangang@kylinos.cn>
---
 net/mptcp/sockopt.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/net/mptcp/sockopt.c b/net/mptcp/sockopt.c
index 79db15903e7a..0efe40be2fde 100644
--- a/net/mptcp/sockopt.c
+++ b/net/mptcp/sockopt.c
@@ -159,10 +159,10 @@ static int mptcp_setsockopt_sol_socket_tstamp(struct mptcp_sock *msk, int optnam
 	lock_sock(sk);
 	mptcp_for_each_subflow(msk, subflow) {
 		struct sock *ssk = mptcp_subflow_tcp_sock(subflow);
-		bool slow = lock_sock_fast(ssk);
 
+		lock_sock(ssk);
 		sock_set_timestamp(ssk, optname, !!val);
-		unlock_sock_fast(ssk, slow);
+		release_sock(ssk);
 	}
 
 	release_sock(sk);
@@ -235,10 +235,10 @@ static int mptcp_setsockopt_sol_socket_timestamping(struct mptcp_sock *msk,
 
 	mptcp_for_each_subflow(msk, subflow) {
 		struct sock *ssk = mptcp_subflow_tcp_sock(subflow);
-		bool slow = lock_sock_fast(ssk);
 
+		lock_sock(ssk);
 		sock_set_timestamping(ssk, optname, timestamping);
-		unlock_sock_fast(ssk, slow);
+		release_sock(ssk);
 	}
 
 	release_sock(sk);
-- 
2.43.0

Re: [PATCH mptcp-net 1/2] mptcp: fix scheduling with atomic in timestamp sockopt

[Matthieu Baerts]

Hi Gang,

On 22/04/2026 11:19, Gang Yan wrote:
> From: Gang Yan <yangang@kylinos.cn>
> 
> Using lock_sock_fast() (atomic context) around sock_set_timestamp()
> and sock_set_timestamping() is unsafe, as both helpers can sleep.
> 
> Replace lock_sock_fast() with sleepable lock_sock()/release_sock()
> to avoid scheduling while atomic panic.
> 
> Assisted-by: Sashiko

I think Reported-by is better here, because Assisted requires the
version, etc. See the Checkpatch error linked to that.

Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes:
https://sashiko.dev/#/patchset/20260420093343.16443-1-gang.yan@linux.dev

> Fixes: 9061f24bf82e ("mptcp: sockopt: propagate timestamp request to subflows")
> Fixes: 6c9a0a0f2333 ("mptcp: setsockopt: convert to mptcp_setsockopt_sol_socket_timestamping()")

Probably the second one is not needed, the issue was already there before.

I can fix all that when applying the patch.

Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.

[PATCH mptcp-next 2/2] mptcp: use sockopt_lock(release)_sock in sockopt

[Gang Yan]

From: Gang Yan <yangang@kylinos.cn>

TCP and the core socket layer all use sockopt_lock_sock()
sockopt_release_sock() in their setsockopt and getsockopt handlers. It
is a BPF-aware wrapper that skips lock acquisition when invoked from a
BPF program, where the socket lock is already held.

Using lock_sock_fast() on subflows requires extra care: the fast path
holds the socket spinlock with BH disabled, creating an atomic context
where sleeping is not allowed.  Switching to sockopt_lock_sock()
avoids the risk of accidentally introducing sleeping operations inside
the lock_sock_fast() critical section.

Signed-off-by: Gang Yan <yangang@kylinos.cn>
---
 net/mptcp/sockopt.c | 121 ++++++++++++++++++++++----------------------
 1 file changed, 60 insertions(+), 61 deletions(-)

diff --git a/net/mptcp/sockopt.c b/net/mptcp/sockopt.c
index 0efe40be2fde..a4a7df4a3c8c 100644
--- a/net/mptcp/sockopt.c
+++ b/net/mptcp/sockopt.c
@@ -72,12 +72,12 @@ static void mptcp_sol_socket_sync_intval(struct mptcp_sock *msk, int optname, in
 	struct mptcp_subflow_context *subflow;
 	struct sock *sk = (struct sock *)msk;
 
-	lock_sock(sk);
+	sockopt_lock_sock(sk);
 	sockopt_seq_inc(msk);
 
 	mptcp_for_each_subflow(msk, subflow) {
 		struct sock *ssk = mptcp_subflow_tcp_sock(subflow);
-		bool slow = lock_sock_fast(ssk);
+		sockopt_lock_sock(ssk);
 
 		switch (optname) {
 		case SO_DEBUG:
@@ -114,10 +114,10 @@ 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);
+		sockopt_release_sock(ssk);
 	}
 
-	release_sock(sk);
+	sockopt_release_sock(sk);
 }
 
 static int mptcp_sol_socket_intval(struct mptcp_sock *msk, int optname, int val)
@@ -156,16 +156,16 @@ static int mptcp_setsockopt_sol_socket_tstamp(struct mptcp_sock *msk, int optnam
 	if (ret)
 		return ret;
 
-	lock_sock(sk);
+	sockopt_lock_sock(sk);
 	mptcp_for_each_subflow(msk, subflow) {
 		struct sock *ssk = mptcp_subflow_tcp_sock(subflow);
 
-		lock_sock(ssk);
+		sockopt_lock_sock(ssk);
 		sock_set_timestamp(ssk, optname, !!val);
-		release_sock(ssk);
+		sockopt_release_sock(ssk);
 	}
 
-	release_sock(sk);
+	sockopt_release_sock(sk);
 	return 0;
 }
 
@@ -231,17 +231,17 @@ static int mptcp_setsockopt_sol_socket_timestamping(struct mptcp_sock *msk,
 	if (ret)
 		return ret;
 
-	lock_sock(sk);
+	sockopt_lock_sock(sk);
 
 	mptcp_for_each_subflow(msk, subflow) {
 		struct sock *ssk = mptcp_subflow_tcp_sock(subflow);
 
-		lock_sock(ssk);
+		sockopt_lock_sock(ssk);
 		sock_set_timestamping(ssk, optname, timestamping);
-		release_sock(ssk);
+		sockopt_release_sock(ssk);
 	}
 
-	release_sock(sk);
+	sockopt_release_sock(sk);
 
 	return 0;
 }
@@ -266,11 +266,11 @@ static int mptcp_setsockopt_sol_socket_linger(struct mptcp_sock *msk, sockptr_t
 	if (ret)
 		return ret;
 
-	lock_sock(sk);
+	sockopt_lock_sock(sk);
 	sockopt_seq_inc(msk);
 	mptcp_for_each_subflow(msk, subflow) {
 		struct sock *ssk = mptcp_subflow_tcp_sock(subflow);
-		bool slow = lock_sock_fast(ssk);
+		sockopt_lock_sock(ssk);
 
 		if (!ling.l_onoff) {
 			sock_reset_flag(ssk, SOCK_LINGER);
@@ -280,10 +280,10 @@ static int mptcp_setsockopt_sol_socket_linger(struct mptcp_sock *msk, sockptr_t
 		}
 
 		subflow->setsockopt_seq = msk->setsockopt_seq;
-		unlock_sock_fast(ssk, slow);
+		sockopt_release_sock(ssk);
 	}
 
-	release_sock(sk);
+	sockopt_release_sock(sk);
 	return 0;
 }
 
@@ -299,10 +299,10 @@ static int mptcp_setsockopt_sol_socket(struct mptcp_sock *msk, int optname,
 	case SO_REUSEADDR:
 	case SO_BINDTODEVICE:
 	case SO_BINDTOIFINDEX:
-		lock_sock(sk);
+		sockopt_lock_sock(sk);
 		ssk = __mptcp_nmpc_sk(msk);
 		if (IS_ERR(ssk)) {
-			release_sock(sk);
+			sockopt_release_sock(sk);
 			return PTR_ERR(ssk);
 		}
 
@@ -317,7 +317,7 @@ static int mptcp_setsockopt_sol_socket(struct mptcp_sock *msk, int optname,
 			else if (optname == SO_BINDTOIFINDEX)
 				sk->sk_bound_dev_if = ssk->sk_bound_dev_if;
 		}
-		release_sock(sk);
+		sockopt_release_sock(sk);
 		return ret;
 	case SO_KEEPALIVE:
 	case SO_PRIORITY:
@@ -395,16 +395,16 @@ static int mptcp_setsockopt_v6(struct mptcp_sock *msk, int optname,
 	case IPV6_V6ONLY:
 	case IPV6_TRANSPARENT:
 	case IPV6_FREEBIND:
-		lock_sock(sk);
+		sockopt_lock_sock(sk);
 		ssk = __mptcp_nmpc_sk(msk);
 		if (IS_ERR(ssk)) {
-			release_sock(sk);
+			sockopt_release_sock(sk);
 			return PTR_ERR(ssk);
 		}
 
 		ret = tcp_setsockopt(ssk, SOL_IPV6, optname, optval, optlen);
 		if (ret != 0) {
-			release_sock(sk);
+			sockopt_release_sock(sk);
 			return ret;
 		}
 
@@ -424,7 +424,7 @@ static int mptcp_setsockopt_v6(struct mptcp_sock *msk, int optname,
 			break;
 		}
 
-		release_sock(sk);
+		sockopt_release_sock(sk);
 		break;
 	}
 
@@ -601,24 +601,24 @@ static int mptcp_setsockopt_sol_tcp_congestion(struct mptcp_sock *msk, sockptr_t
 	cap_net_admin = ns_capable(sock_net(sk)->user_ns, CAP_NET_ADMIN);
 
 	ret = 0;
-	lock_sock(sk);
+	sockopt_lock_sock(sk);
 	sockopt_seq_inc(msk);
 	mptcp_for_each_subflow(msk, subflow) {
 		struct sock *ssk = mptcp_subflow_tcp_sock(subflow);
 		int err;
 
-		lock_sock(ssk);
+		sockopt_lock_sock(ssk);
 		err = tcp_set_congestion_control(ssk, name, true, cap_net_admin);
 		if (err < 0 && ret == 0)
 			ret = err;
 		subflow->setsockopt_seq = msk->setsockopt_seq;
-		release_sock(ssk);
+		sockopt_release_sock(ssk);
 	}
 
 	if (ret == 0)
 		strscpy(msk->ca_name, name, sizeof(msk->ca_name));
 
-	release_sock(sk);
+	sockopt_release_sock(sk);
 	return ret;
 }
 
@@ -633,10 +633,10 @@ static int __mptcp_setsockopt_set_val(struct mptcp_sock *msk, int max,
 		struct sock *ssk = mptcp_subflow_tcp_sock(subflow);
 		int ret;
 
-		lock_sock(ssk);
+		sockopt_lock_sock(ssk);
 		ret = set_val(ssk, val);
 		err = err ? : ret;
-		release_sock(ssk);
+		sockopt_release_sock(ssk);
 	}
 
 	if (!err) {
@@ -657,9 +657,9 @@ static int __mptcp_setsockopt_sol_tcp_cork(struct mptcp_sock *msk, int val)
 	mptcp_for_each_subflow(msk, subflow) {
 		struct sock *ssk = mptcp_subflow_tcp_sock(subflow);
 
-		lock_sock(ssk);
+		sockopt_lock_sock(ssk);
 		__tcp_sock_set_cork(ssk, !!val);
-		release_sock(ssk);
+		sockopt_release_sock(ssk);
 	}
 	if (!val)
 		mptcp_check_and_set_pending(sk);
@@ -677,9 +677,9 @@ static int __mptcp_setsockopt_sol_tcp_nodelay(struct mptcp_sock *msk, int val)
 	mptcp_for_each_subflow(msk, subflow) {
 		struct sock *ssk = mptcp_subflow_tcp_sock(subflow);
 
-		lock_sock(ssk);
+		sockopt_lock_sock(ssk);
 		__tcp_sock_set_nodelay(ssk, !!val);
-		release_sock(ssk);
+		sockopt_release_sock(ssk);
 	}
 	if (val)
 		mptcp_check_and_set_pending(sk);
@@ -697,11 +697,11 @@ static int mptcp_setsockopt_sol_ip_set(struct mptcp_sock *msk, int optname,
 	if (err != 0)
 		return err;
 
-	lock_sock(sk);
+	sockopt_lock_sock(sk);
 
 	ssk = __mptcp_nmpc_sk(msk);
 	if (IS_ERR(ssk)) {
-		release_sock(sk);
+		sockopt_release_sock(sk);
 		return PTR_ERR(ssk);
 	}
 
@@ -722,13 +722,13 @@ static int mptcp_setsockopt_sol_ip_set(struct mptcp_sock *msk, int optname,
 			   READ_ONCE(inet_sk(sk)->local_port_range));
 		break;
 	default:
-		release_sock(sk);
+		sockopt_release_sock(sk);
 		WARN_ON_ONCE(1);
 		return -EOPNOTSUPP;
 	}
 
 	sockopt_seq_inc(msk);
-	release_sock(sk);
+	sockopt_release_sock(sk);
 	return 0;
 }
 
@@ -744,18 +744,17 @@ static int mptcp_setsockopt_v4_set_tos(struct mptcp_sock *msk, int optname,
 	if (err != 0)
 		return err;
 
-	lock_sock(sk);
+	sockopt_lock_sock(sk);
 	sockopt_seq_inc(msk);
 	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);
+		sockopt_lock_sock(ssk);
 		__ip_sock_set_tos(ssk, val);
-		unlock_sock_fast(ssk, slow);
+		sockopt_release_sock(ssk);
 	}
-	release_sock(sk);
+	sockopt_release_sock(sk);
 
 	return 0;
 }
@@ -784,7 +783,7 @@ static int mptcp_setsockopt_first_sf_only(struct mptcp_sock *msk, int level, int
 	int ret;
 
 	/* Limit to first subflow, before the connection establishment */
-	lock_sock(sk);
+	sockopt_lock_sock(sk);
 	ssk = __mptcp_nmpc_sk(msk);
 	if (IS_ERR(ssk)) {
 		ret = PTR_ERR(ssk);
@@ -794,7 +793,7 @@ static int mptcp_setsockopt_first_sf_only(struct mptcp_sock *msk, int level, int
 	ret = tcp_setsockopt(ssk, level, optname, optval, optlen);
 
 unlock:
-	release_sock(sk);
+	sockopt_release_sock(sk);
 	return ret;
 }
 
@@ -842,7 +841,7 @@ static int mptcp_setsockopt_sol_tcp(struct mptcp_sock *msk, int optname,
 	if (ret)
 		return ret;
 
-	lock_sock(sk);
+	sockopt_lock_sock(sk);
 	switch (optname) {
 	case TCP_INQ:
 		if (val < 0 || val > 1)
@@ -885,7 +884,7 @@ static int mptcp_setsockopt_sol_tcp(struct mptcp_sock *msk, int optname,
 		ret = -ENOPROTOOPT;
 	}
 
-	release_sock(sk);
+	sockopt_release_sock(sk);
 	return ret;
 }
 
@@ -909,9 +908,9 @@ int mptcp_setsockopt(struct sock *sk, int level, int optname,
 	 * is in TCP fallback, when TCP socket options are passed through
 	 * to the one remaining subflow.
 	 */
-	lock_sock(sk);
+	sockopt_lock_sock(sk);
 	ssk = __mptcp_tcp_fallback(msk);
-	release_sock(sk);
+	sockopt_release_sock(sk);
 	if (ssk)
 		return tcp_setsockopt(ssk, level, optname, optval, optlen);
 
@@ -934,7 +933,7 @@ static int mptcp_getsockopt_first_sf_only(struct mptcp_sock *msk, int level, int
 	struct sock *ssk;
 	int ret;
 
-	lock_sock(sk);
+	sockopt_lock_sock(sk);
 	ssk = msk->first;
 	if (ssk)
 		goto get;
@@ -949,7 +948,7 @@ static int mptcp_getsockopt_first_sf_only(struct mptcp_sock *msk, int level, int
 	ret = tcp_getsockopt(ssk, level, optname, optval, optlen);
 
 out:
-	release_sock(sk);
+	sockopt_release_sock(sk);
 	return ret;
 }
 
@@ -1120,7 +1119,7 @@ static int mptcp_getsockopt_tcpinfo(struct mptcp_sock *msk, char __user *optval,
 
 	infoptr = optval + sfd.size_subflow_data;
 
-	lock_sock(sk);
+	sockopt_lock_sock(sk);
 
 	mptcp_for_each_subflow(msk, subflow) {
 		struct sock *ssk = mptcp_subflow_tcp_sock(subflow);
@@ -1133,7 +1132,7 @@ static int mptcp_getsockopt_tcpinfo(struct mptcp_sock *msk, char __user *optval,
 			tcp_get_info(ssk, &info);
 
 			if (copy_to_user(infoptr, &info, sfd.size_user)) {
-				release_sock(sk);
+				sockopt_release_sock(sk);
 				return -EFAULT;
 			}
 
@@ -1143,7 +1142,7 @@ static int mptcp_getsockopt_tcpinfo(struct mptcp_sock *msk, char __user *optval,
 		}
 	}
 
-	release_sock(sk);
+	sockopt_release_sock(sk);
 
 	sfd.num_subflows = sfcount;
 
@@ -1212,7 +1211,7 @@ static int mptcp_getsockopt_subflow_addrs(struct mptcp_sock *msk, char __user *o
 
 	addrptr = optval + sfd.size_subflow_data;
 
-	lock_sock(sk);
+	sockopt_lock_sock(sk);
 
 	mptcp_for_each_subflow(msk, subflow) {
 		struct sock *ssk = mptcp_subflow_tcp_sock(subflow);
@@ -1225,7 +1224,7 @@ static int mptcp_getsockopt_subflow_addrs(struct mptcp_sock *msk, char __user *o
 			mptcp_get_sub_addrs(ssk, &a);
 
 			if (copy_to_user(addrptr, &a, sfd.size_user)) {
-				release_sock(sk);
+				sockopt_release_sock(sk);
 				return -EFAULT;
 			}
 
@@ -1235,7 +1234,7 @@ static int mptcp_getsockopt_subflow_addrs(struct mptcp_sock *msk, char __user *o
 		}
 	}
 
-	release_sock(sk);
+	sockopt_release_sock(sk);
 
 	sfd.num_subflows = sfcount;
 
@@ -1321,7 +1320,7 @@ static int mptcp_getsockopt_full_info(struct mptcp_sock *msk, char __user *optva
 				     sizeof(struct mptcp_subflow_info));
 	tcpinfoptr = u64_to_user_ptr(mfi.tcp_info);
 
-	lock_sock(sk);
+	sockopt_lock_sock(sk);
 	mptcp_for_each_subflow(msk, subflow) {
 		struct sock *ssk = mptcp_subflow_tcp_sock(subflow);
 		struct mptcp_subflow_info sfinfo;
@@ -1351,7 +1350,7 @@ static int mptcp_getsockopt_full_info(struct mptcp_sock *msk, char __user *optva
 		tcpinfoptr += mfi.size_tcpinfo_user;
 		sfinfoptr += mfi.size_sfinfo_user;
 	}
-	release_sock(sk);
+	sockopt_release_sock(sk);
 
 	mfi.num_subflows = sfcount;
 	if (mptcp_put_full_info(&mfi, optval, copylen, optlen))
@@ -1360,7 +1359,7 @@ static int mptcp_getsockopt_full_info(struct mptcp_sock *msk, char __user *optva
 	return 0;
 
 fail_release:
-	release_sock(sk);
+	sockopt_release_sock(sk);
 	return -EFAULT;
 }
 
@@ -1515,9 +1514,9 @@ int mptcp_getsockopt(struct sock *sk, int level, int optname,
 	 * is in TCP fallback, when socket options are passed through
 	 * to the one remaining subflow.
 	 */
-	lock_sock(sk);
+	sockopt_lock_sock(sk);
 	ssk = __mptcp_tcp_fallback(msk);
-	release_sock(sk);
+	sockopt_release_sock(sk);
 	if (ssk)
 		return tcp_getsockopt(ssk, level, optname, optval, option);
 
-- 
2.43.0

Re: [PATCH mptcp-next 2/2] mptcp: use sockopt_lock(release)_sock in sockopt

[Matthieu Baerts]

Hi Gang,

On 22/04/2026 11:19, Gang Yan wrote:
> From: Gang Yan <yangang@kylinos.cn>
> 
> TCP and the core socket layer all use sockopt_lock_sock()
> sockopt_release_sock() in their setsockopt and getsockopt handlers. It
> is a BPF-aware wrapper that skips lock acquisition when invoked from a
> BPF program, where the socket lock is already held.
> 
> Using lock_sock_fast() on subflows requires extra care: the fast path
> holds the socket spinlock with BH disabled, creating an atomic context
> where sleeping is not allowed.  Switching to sockopt_lock_sock()
> avoids the risk of accidentally introducing sleeping operations inside
> the lock_sock_fast() critical section.

Good catch, I guess we need this too. I think this patch can be seen as
a fix as well, maybe with this tag?

  24426654ed3a ("bpf: net: Avoid sk_setsockopt() taking sk lock when
called from bpf")

WDYT?

Also, from the same BPF series, we probably need this, no?

  e42c7beee71d ("bpf: net: Consider has_current_bpf_ctx() when testing
capable() in sk_setsockopt()")

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.

Re: [PATCH mptcp-next 2/2] mptcp: use sockopt_lock(release)_sock in sockopt

[gang.yan]

April 27, 2026 at 10:47 PM, "Matthieu Baerts" <matttbe@kernel.org mailto:matttbe@kernel.org?to=%22Matthieu%20Baerts%22%20%3Cmatttbe%40kernel.org%3E > wrote:


> 
> Hi Gang,
> 
> On 22/04/2026 11:19, Gang Yan wrote:
> 
> > 
> > From: Gang Yan <yangang@kylinos.cn>
> >  
> >  TCP and the core socket layer all use sockopt_lock_sock()
> >  sockopt_release_sock() in their setsockopt and getsockopt handlers. It
> >  is a BPF-aware wrapper that skips lock acquisition when invoked from a
> >  BPF program, where the socket lock is already held.
> >  
> >  Using lock_sock_fast() on subflows requires extra care: the fast path
> >  holds the socket spinlock with BH disabled, creating an atomic context
> >  where sleeping is not allowed. Switching to sockopt_lock_sock()
> >  avoids the risk of accidentally introducing sleeping operations inside
> >  the lock_sock_fast() critical section.
> > 
> Good catch, I guess we need this too. I think this patch can be seen as
> a fix as well, maybe with this tag?
> 
>  24426654ed3a ("bpf: net: Avoid sk_setsockopt() taking sk lock when
> called from bpf")
> 
> WDYT?
> 
> Also, from the same BPF series, we probably need this, no?
> 
>  e42c7beee71d ("bpf: net: Consider has_current_bpf_ctx() when testing
> capable() in sk_setsockopt()")

Great suggestions!

I'm a bit busy with ongoing work recently, but will check those two commits
carefully this week later. If these changes are necessary, I will send out a
new complete patch series. If not required separately, I will post relevant
updates in the mailing list thread accordingly.

Thanks
Gang
> 
> Cheers,
> Matt
> -- 
> Sponsored by the NGI0 Core fund.
>

Re: [PATCH mptcp-net 0/2] mptcp: replace lock_sock_fast with sleepable lock

[MPTCP CI]

Hi Gang,

Thank you for your modifications, that's great!

Our CI did some validations and here is its report:

- KVM Validation: normal (except selftest_mptcp_join): Success! ✅
- KVM Validation: normal (only selftest_mptcp_join): Success! ✅
- KVM Validation: debug (except selftest_mptcp_join): Success! ✅
- KVM Validation: debug (only selftest_mptcp_join): Success! ✅
- KVM Validation: btf-normal (only bpftest_all): Success! ✅
- KVM Validation: btf-debug (only bpftest_all): Success! ✅
- Task: https://github.com/multipath-tcp/mptcp_net-next/actions/runs/24844419761

Initiator: Matthieu Baerts (NGI0)
Commits: https://github.com/multipath-tcp/mptcp_net-next/commits/e433f0995d36
Patchwork: https://patchwork.kernel.org/project/mptcp/list/?series=1084186


If there are some issues, you can reproduce them using the same environment as
the one used by the CI thanks to a docker image, e.g.:

    $ cd [kernel source code]
    $ docker run -v "${PWD}:${PWD}:rw" -w "${PWD}" --privileged --rm -it \
        --pull always mptcp/mptcp-upstream-virtme-docker:latest \
        auto-normal

For more details:

    https://github.com/multipath-tcp/mptcp-upstream-virtme-docker


Please note that despite all the efforts that have been already done to have a
stable tests suite when executed on a public CI like here, it is possible some
reported issues are not due to your modifications. Still, do not hesitate to
help us improve that ;-)

Cheers,
MPTCP GH Action bot
Bot operated by Matthieu Baerts (NGI0 Core)

Re: [PATCH mptcp-net 0/2] mptcp: replace lock_sock_fast with sleepable lock

[Matthieu Baerts]

Hi Gang,

On 22/04/2026 11:19, Gang Yan wrote:
> From: Gang Yan <yangang@kylinos.cn>
> 
> Hi Matt,

(I'm not the only one here, anybody is very welcome to review the
patches: if you put only my name, other people will not tend to review
your patches ;) )

> I make some progress about the issue sashiko mentioned in:
> https://sashiko.dev/#/patchset/20260420093343.16443-1-gang.yan@linux.dev
> 
> The problem does exist,though the trigger conditions seem quite strict.
> 
> asdasda shjaksdjh askjd hjklajsdhfj klasjd aklshd kljasldkj akjlsd klklk

(Not sure what this ↑ means)

I only applied patch 1/2:

New patches for t/upstream-net and t/upstream:
- 38bf59aed203: mptcp: fix scheduling with atomic in timestamp sockopt
- Results: 6d491ca82084..1198f2f92b39 (export-net)
- Results: 2f9eb2a59db0..3c2b57fddf87 (export)

Tests are now in progress:

- export-net:
https://github.com/multipath-tcp/mptcp_net-next/commit/42417392e5ff4cba41b6b585233d57bd9102f2da/checks
- export:
https://github.com/multipath-tcp/mptcp_net-next/commit/9b2ff7d1da660653ed4d10f0888aa499b7988b54/checks

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.

Re: [PATCH mptcp-net 0/2] mptcp: replace lock_sock_fast with sleepable lock

[gang.yan]

April 27, 2026 at 11:04 PM, "Matthieu Baerts" <matttbe@kernel.org mailto:matttbe@kernel.org?to=%22Matthieu%20Baerts%22%20%3Cmatttbe%40kernel.org%3E > wrote:


> 
> Hi Gang,
> 
> On 22/04/2026 11:19, Gang Yan wrote:
> 
> > 
> > From: Gang Yan <yangang@kylinos.cn>
> >  
> >  Hi Matt,
> > 
> (I'm not the only one here, anybody is very welcome to review the
> patches: if you put only my name, other people will not tend to review
> your patches ;) )
Got it, thanks for your reminder.

> 
> > 
> > I make some progress about the issue sashiko mentioned in:
> >  https://sashiko.dev/#/patchset/20260420093343.16443-1-gang.yan@linux.dev
> >  
> >  The problem does exist,though the trigger conditions seem quite strict.
> >  
> >  asdasda shjaksdjh askjd hjklajsdhfj klasjd aklshd kljasldkj akjlsd klklk
> > 
> (Not sure what this ↑ means)

The random garbled content was caused by accidental typing due to my local
environment issue, which was a careless mistake on my part.

Recently, I’m actively learning and getting familiar with the b4 tool. 
I will standardize my patch submission process and ensure that such messy content
and irrelevant errors will not appear in future patches.

Thanks
Gang

> 
> I only applied patch 1/2:
> 
> New patches for t/upstream-net and t/upstream:
> - 38bf59aed203: mptcp: fix scheduling with atomic in timestamp sockopt
> - Results: 6d491ca82084..1198f2f92b39 (export-net)
> - Results: 2f9eb2a59db0..3c2b57fddf87 (export)
> 
> Tests are now in progress:
> 
> - export-net:
> https://github.com/multipath-tcp/mptcp_net-next/commit/42417392e5ff4cba41b6b585233d57bd9102f2da/checks
> - export:
> https://github.com/multipath-tcp/mptcp_net-next/commit/9b2ff7d1da660653ed4d10f0888aa499b7988b54/checks
> 
> Cheers,
> Matt
> -- 
> Sponsored by the NGI0 Core fund.
>