[PATCH net 0/2] net: restore acquire ordering for two remaining lockless lookups

[Hang Nan <2122295973@qq.com>]

Hello,

commit 5b5d8f351dd9 ("net: restore refcount ordering for lockless socket access")
restored the acquire ordering that refcount_inc_not_zero() lost in the
2019 refcount_t consolidation fb041bb7c0a9, for the IPv4/IPv6
established lookups, inet_twsk_purge() and bpf_sk_assign().

The requirement is not the reference itself, but the second validation
that follows it: when a lookup takes a reference and then re-reads state
that the teardown path mutates, that re-read must not be reordered before
the acquisition, otherwise the lookup can hand back an object whose state
has already been cleared.

Two sites of that exact shape are left in net/.  Both are one-line
changes and neither alters behaviour on strongly ordered CPUs:

  net/mptcp/token.c        mptcp_token_get_sock() re-reads msk->token
                           after taking the reference, while
                           mptcp_token_destroy() clears it with
                           WRITE_ONCE(msk->token, 0).  The lookup is
                           driven by an inbound MP_JOIN SYN, so it is
                           remotely reachable on a listener with MPTCP
                           enabled.  mptcp_token_iter_next() has the same
                           shape.
  net/core/sock_reuseport.c  reuseport_migrate_sock() hands a listener to
                           tcp_filter()/tcp_check_req(), which read its
                           fields immediately.

Both are converted to refcount_inc_not_zero_acquire().

For completeness: the other 90 refcount_inc_not_zero() sites in net/ are
either protected by an RCU section across the uses, or take the
reference only to pin the object alive and do not re-validate any field
afterwards (l2tp, nf_conntrack, cls_flower, tipc crypto...).  The two
conntrack lookups that do re-validate already call
smp_acquire__after_ctrl_dep() explicitly.

This is an ordering fix, not a fix for an observed crash: I do not have a
syzbot report for either site, and on x86-64 the reordering is not
observable.  Reviewers should treat it as making the existing
re-validation meaningful on weakly ordered CPUs, in line with the
accepted change above.

Hang Nan (2):
  net: mptcp: take token lookup references with acquire ordering
  net: core: take the reuseport migration reference with acquire ordering

 net/core/sock_reuseport.c | 3 ++-
 net/mptcp/token.c         | 4 ++--
 2 files changed, 4 insertions(+), 3 deletions(-)

-- 
2.53.0