[BUG] bpf: tcp: bpf_tcp_ops_set_rcvlowat() missing from BTF with clang KCSAN

[Breno Leitao <leitao@debian.org>]

My arm64 KCSAN builds of linux-next fail since next-20261015, because
bpf_tcp_ops_set_rcvlowat() is missing from the vmlinux BTF:

  WARN: resolve_btfids: no BTF func for kfunc bpf_tcp_ops_set_rcvlowat in bpf_tcp_ops_set_rcvlowat_kfunc_set
  WARN: resolve_btfids: unresolved symbol bpf_tcp_ops_set_rcvlowat
  Failed to generate BTF for vmlinux
  Try to disable CONFIG_DEBUG_INFO_BTF
  make[4]: *** [scripts/Makefile.vmlinux:72: vmlinux.unstripped] Error 1

This is clang 22.1.3 and pahole 1.31 (current pahole master behaves the
same), with CONFIG_KCSAN=y, CONFIG_DEBUG_INFO_BTF=y and CONFIG_WERROR=y.
v7.4-rc1 is affected as well. With pahole 1.31, the same config without
KCSAN builds fine.

The kfunc came with 5f549c1e49f3 ("bpf: tcp: Add kfunc to adjust
sk->sk_rcvlowat."), and 201a454df948 ("resolve_btfids: Fix the
--fatal_warnings exit status") made the missing BTF fatal with
CONFIG_WERROR. Without CONFIG_WERROR the kernel builds, but bpf_tcp_ops
is never registered:

  initcall __bpf_tcp_ops_init+0x0/0x70 returned -22 after 302 usecs

This seems similar to pahole behaviour sched_ext hit with a bool
argument, discussed in [2] and worked around in f2f095c87603
("sched_ext: Work around pahole 1.32 dropping
scx_bpf_task_set_lazy_resched() from BTF").

Here the argument is an int that clang reassigns, its location list has
no DW_OP_entry_value, and pahole 1.31 drops it as well, so staying on
pahole 1.31 does not help.

Not reassigning the parameter is a workaround for me, with any pahole: clang
then describes @rcvlowat in w1 from the entry, the kfunc is back in BTF,
and __bpf_tcp_ops_init() returns 0 (tested in virtme):

diff --git a/net/ipv4/bpf_tcp_ops.c b/net/ipv4/bpf_tcp_ops.c
index 2ba73dd6c52cce..1afa6bd7f508ef 100644
--- a/net/ipv4/bpf_tcp_ops.c
+++ b/net/ipv4/bpf_tcp_ops.c
@@ -370,10 +370,9 @@ __bpf_kfunc int bpf_tcp_ops_set_rcvlowat(struct sock *sk, int rcvlowat,
 	if (moff == offsetof(struct bpf_tcp_ops, dequeue_rcvq))
 		wakeup = true;

-	if (rcvlowat < 0)
-		rcvlowat = INT_MAX;
-
-	return __tcp_set_rcvlowat(sk, rcvlowat, wakeup);
+	/* Reassigning @rcvlowat can make pahole drop this kfunc from BTF. */
+	return __tcp_set_rcvlowat(sk, rcvlowat < 0 ? INT_MAX : rcvlowat,
+				  wakeup);
 }

 __bpf_kfunc_end_defs();

Would this be acceptable?

[1] https://lore.kernel.org/all/DLRKT5MG6W2P.2V1P0QD4GQEKY@gmail.com/
[2] https://lore.kernel.org/all/7c139810be5ffc9764ed4236efc28794@kernel.org/