Re: [PATCH mptcp-next v5 4/6] mptcp: reject sockopt requiring ssks' lock in BPF context

[gang.yan@linux.dev]

May 25, 2026 at 4:32 PM, "Paolo Abeni" <pabeni@redhat.com mailto:pabeni@redhat.com?to=%22Paolo%20Abeni%22%20%3Cpabeni%40redhat.com%3E > wrote:


> 
> On 5/22/26 11:12 AM, Gang Yan wrote:
> 
> > 
> > @@ -600,6 +609,9 @@ static int mptcp_setsockopt_sol_tcp_congestion(struct mptcp_sock *msk, sockptr_t
> >  
> >  cap_net_admin = sockopt_ns_capable(sock_net(sk)->user_ns, CAP_NET_ADMIN);
> >  
> >  + if (has_current_bpf_ctx())
> >  + return -EOPNOTSUPP;
> > 
> I think it would be better to move the check earlier and drop the
> previous patch.
> 
> Possibly it would be considered avoiding touching in patch 2 the other
> functions where EBPF support is disabled here, but I have mixed feeling
> WRT this later option, due to code consistency. Not a big deal either way.
> 
> /P
>

Hi Paolo,

Thanks for your review.

Would you mind reviewing patch 1 separately? I noticed that patch 1 is doing
something different from the rest. Patches 2–6 focus on MPTCP sockopt issues
in BPF context — they should really be a separate series, and I'll iterate on
a new version for them later.

My current idea is to build on patch 5 and patch 6 to try supporting a subset
of setsockopt operations in BPF environment. For operations that need to take
the subflow lock (including the first subflow), we can use has_current_bpf_ctx
to return -EOPNOTSUPP.

WDYT?

Thanks,
Gang