Re: [PATCH net] mptcp: upgrade network refcount before socket lock

[Matthieu Baerts <matttbe@kernel.org>]

Hi Runyu,

On 09/08/2026 11:19, Runyu Xiao wrote:
> sk_net_refcnt_upgrade() calls get_net_track() with GFP_KERNEL and can enter
> direct reclaim. Calling it while holding the newly created subflow socket
> lock can create a reclaim-to-socket-lock dependency cycle.
> 
> Upgrade the network reference before taking the socket lock. The socket is
> newly created and has not been exposed to other code at this point, so the
> fields changed by sk_net_refcnt_upgrade() are not accessed concurrently.
> The error path still releases the socket normally after the upgrade.

Thank you for the patch! Even if I agree with Gang that the commit
message could be improved, the code looks good to me, and probably best
not to increase the traffic on the netdev list. So it looks good to me:

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

@Net maintainers: this patch can be applied to net directly.

> The PatchProof static-analysis tool detected a GFP_KERNEL allocation while
> the socket lock is held. Manual source review of v7.1.5 and current
> mainline confirmed the lock and allocation ordering.
> 
> A source-level check found `sk_net_refcnt_upgrade()` after
> `lock_sock_nested()` in the original function and before it after this
> change. A POSIX-thread lock-order model made the reclaim lock unavailable
> while the socket lock was held, observed `EBUSY` for the reclaim lock, and
> then completed with the reclaim-first order. The model checks the ordering
> invariant only; it does not execute the kernel MPTCP path. No live lockdep
> MPTCP test or reclaim fault injection was run.

Interesting. By chance, any reproducer to share?

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