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

[gang.yan@linux.dev]

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.
>