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

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

[Breno Leitao]

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/

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

[Jiayuan Chen]

Thanks for the report !


On 11/6/26 7:38 PM, Breno Leitao wrote:
> 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



Has pahole fixed this issue?


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


This sets a bad example for future kfuncs, as if kfunc arguments must not be reassigned......


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

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

[Breno Leitao]

On Fri, Nov 06, 2026 at 09:16:24PM +0800, Jiayuan Chen wrote:
> Thanks for the report !
> 
> 
> On 11/6/26 7:38 PM, Breno Leitao wrote:
> > 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
> 
> 
> 
> Has pahole fixed this issue?

I don't think so, see the line below:

> > This is clang 22.1.3 and pahole 1.31 (current pahole master behaves the
> > same),

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

[Kuniyuki Iwashima]

On Fri, 06 Nov 2026 07:58:01 -0800, Breno Leitao wrote:
> On Fri, Nov 06, 2026 at 09:16:24PM +0800, Jiayuan Chen wrote:
> > Thanks for the report !
> > 
> > 
> > On 11/6/26 7:38 PM, Breno Leitao wrote:
> > > 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
> > 
> > 
> > 
> > Has pahole fixed this issue?
> 
> I don't think so, see the line below:

Could you try this ?

---8<---
diff --git a/dwarf_loader.c b/dwarf_loader.c
index 01049e9802a3..92793ae6cf98 100644
--- a/dwarf_loader.c
+++ b/dwarf_loader.c
@@ -1782,18 +1782,32 @@ static uint64_t dwarf_op__const_value(const Dwarf_Op *op)
 	return op->number;
 }
 
+static bool cu__is_arg_reg(const struct cu *cu, int reg)
+{
+	if (cu->register_params[0] < 0)
+		return reg >= DW_OP_reg0;
+
+	for (int i = 0; i < cu->nr_register_params; i++) {
+		if (cu->register_params[i] == reg)
+			return true;
+	}
+	return false;
+}
+
 static void parameter__set_loc_reg(struct parameter *parm, int reg)
 {
 	if (parm->loc_reg == PARAMETER_UNKNOWN_REG)
 		parm->loc_reg = reg;
 }
 
-static void parameter__record_loc_reg(struct parameter *parm, int reg,
-				      int64_t offset, bool is_deref,
-				      uint8_t size)
+static void parameter__record_loc_reg(struct parameter *parm, const struct cu *cu,
+				      bool for_inline, int reg, int64_t offset,
+				      bool is_deref, uint8_t size)
 {
 	if (reg < DW_OP_reg0 || !size)
 		return;
+	if (!for_inline && (is_deref || !cu__is_arg_reg(cu, reg)))
+		return;
 
 	parameter__set_loc_reg(parm, reg);
 
@@ -1920,7 +1934,8 @@ static void parameter__finish_piece_decode(struct parameter *parm, Dwarf_Die *di
  * ABI-preserved or should be replaced by the single used member candidate.
  */
 static void parameter__multi_exprs(Dwarf_Op *expr, int loc_num, struct cu *cu,
-				   size_t exprlen, struct parameter *parm)
+				   size_t exprlen, struct parameter *parm,
+				   bool for_inline)
 {
 	int regs[2], nregs = 0;
 	uint64_t piece_size = 0;
@@ -1951,11 +1966,12 @@ static void parameter__multi_exprs(Dwarf_Op *expr, int loc_num, struct cu *cu,
 		switch (expr[0].atom) {
 		case DW_OP_reg0 ... DW_OP_reg31:
 			if (loc_num == 0)
-				parameter__record_loc_reg(parm, expr[0].atom, 0, false, size);
+				parameter__record_loc_reg(parm, cu, for_inline, expr[0].atom,
+							  0, false, size);
 			return;
 		case DW_OP_breg0 ... DW_OP_breg31:
 			if (loc_num == 0)
-				parameter__record_loc_reg(parm,
+				parameter__record_loc_reg(parm, cu, for_inline,
 							  expr[0].atom - DW_OP_breg0 + DW_OP_reg0,
 							  dwarf_op__snumber(&expr[0]),
 							  !had_stack_value, size);
@@ -1994,14 +2010,15 @@ static void parameter__multi_exprs(Dwarf_Op *expr, int loc_num, struct cu *cu,
 			if (off < cu->addr_size || parm->loc_reg == PARAMETER_UNKNOWN_REG) {
 				uint8_t size = parameter__loc_size(parm, cu);
 
-				parameter__record_loc_reg(parm, expr[i].atom, 0, false, size);
+				parameter__record_loc_reg(parm, cu, for_inline, expr[i].atom,
+							  0, false, size);
 			}
 		} else {
 			reg_pieces = false;
 		}
 	}
 
-	if (loc_num == 0 && reg_pieces && nregs == ARRAY_SIZE(regs) &&
+	if (for_inline && loc_num == 0 && reg_pieces && nregs == ARRAY_SIZE(regs) &&
 	    piece_size == parm->type_byte_size)
 		parameter__record_loc_reg_pair(parm, DW_OP_reg0 + regs[0],
 					       DW_OP_reg0 + regs[1]);
@@ -2009,7 +2026,7 @@ static void parameter__multi_exprs(Dwarf_Op *expr, int loc_num, struct cu *cu,
 
 static void parameter__decode_location(Dwarf_Attribute *attr, struct conf_load *conf,
 				       struct cu *cu, Dwarf_Die *die,
-				       struct parameter *parm)
+				       struct parameter *parm, bool for_inline)
 {
 	Dwarf_Addr base, start, end;
 	Dwarf_Op *expr, *entry_ops;
@@ -2051,7 +2068,7 @@ static void parameter__decode_location(Dwarf_Attribute *attr, struct conf_load *
 			continue;
 
 		if (exprlen != 1) {
-			parameter__multi_exprs(expr, loc_num, cu, exprlen, parm);
+			parameter__multi_exprs(expr, loc_num, cu, exprlen, parm, for_inline);
 			continue;
 		}
 
@@ -2060,11 +2077,12 @@ static void parameter__decode_location(Dwarf_Attribute *attr, struct conf_load *
 		switch (expr->atom) {
 		case DW_OP_reg0 ... DW_OP_reg31:
 			if (loc_num == 0)
-				parameter__record_loc_reg(parm, expr->atom, 0, false, size);
+				parameter__record_loc_reg(parm, cu, for_inline, expr->atom,
+							  0, false, size);
 			break;
 		case DW_OP_breg0 ... DW_OP_breg31:
 			if (loc_num == 0)
-				parameter__record_loc_reg(parm,
+				parameter__record_loc_reg(parm, cu, for_inline,
 							  expr->atom - DW_OP_breg0 + DW_OP_reg0,
 							  dwarf_op__snumber(expr),
 							  had_deref || !had_stack_value,
@@ -2103,7 +2121,8 @@ static void parameter__decode_location(Dwarf_Attribute *attr, struct conf_load *
 			if (dwarf_getlocation_attr(attr, expr, &entry_attr) == 0 &&
 			    dwarf_getlocation(&entry_attr, &entry_ops, &entry_len) == 0 &&
 			    entry_len == 1 && dwarf_op__is_reg(entry_ops->atom))
-				parameter__record_loc_reg(parm, entry_ops->atom, 0, false, size);
+				parameter__record_loc_reg(parm, cu, for_inline, entry_ops->atom,
+							  0, false, size);
 			break;
 		}
 	}
@@ -2171,7 +2190,8 @@ static struct parameter *parameter__new(Dwarf_Die *die, struct cu *cu, struct co
 			parameter__record_attr_const_value(&attr, cu, parm);
 		parm->has_loc = dwarf_attr(die, DW_AT_location, &attr) != NULL;
 		if (parm->has_loc)
-			parameter__decode_location(&attr, conf, cu, die, parm);
+			parameter__decode_location(&attr, conf, cu, die, parm,
+						   ftype == NULL);
 	}
 
 	return parm;
---8<---

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

[Breno Leitao]

On Fri, Nov 06, 2026 at 07:05:25PM +0000, Kuniyuki Iwashima wrote:
> On Fri, 06 Nov 2026 07:58:01 -0800, Breno Leitao wrote:
> > On Fri, Nov 06, 2026 at 09:16:24PM +0800, Jiayuan Chen wrote:
> > > Thanks for the report !
> > > 
> > > 
> > > On 11/6/26 7:38 PM, Breno Leitao wrote:
> > > > 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
> > > 
> > > 
> > > 
> > > Has pahole fixed this issue?
> > 
> > I don't think so, see the line below:
> 
> Could you try this ?

Thanks, it fixes my build. I tested it on top of pahole master (9eb594d)
with next-20261105 and clang 22.1.3:

 - arm64 KCSAN, CONFIG_WERROR=y: vmlinux links again,
   bpf_tcp_ops_set_rcvlowat() is back in BTF, __bpf_tcp_ops_init()
   returns 0, and progs/tcp_autolowat.c from the selftests loads.

 - It also brings back scx_bpf_tid_to_task() that was work arounded by
   tejun.

Feel free to add my "Tested-by: Breno Leitao <leitao@debian.org>" tag.

--breno

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

[Arnaldo Carvalho de Melo]

On Mon, Nov 09, 2026 at 04:33:40AM -0800, Breno Leitao wrote:
> On Fri, Nov 06, 2026 at 07:05:25PM +0000, Kuniyuki Iwashima wrote:
> > On Fri, 06 Nov 2026 07:58:01 -0800, Breno Leitao wrote:
> > > On Fri, Nov 06, 2026 at 09:16:24PM +0800, Jiayuan Chen wrote:
> > > > Thanks for the report !
> > > > 
> > > > 
> > > > On 11/6/26 7:38 PM, Breno Leitao wrote:
> > > > > 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
> > > > Has pahole fixed this issue?
> > > 
> > > I don't think so, see the line below:
> > 
> > Could you try this ?
> 
> Thanks, it fixes my build. I tested it on top of pahole master (9eb594d)
> with next-20261105 and clang 22.1.3:
> 
>  - arm64 KCSAN, CONFIG_WERROR=y: vmlinux links again,
>    bpf_tcp_ops_set_rcvlowat() is back in BTF, __bpf_tcp_ops_init()
>    returns 0, and progs/tcp_autolowat.c from the selftests loads.
> 
>  - It also brings back scx_bpf_tid_to_task() that was work arounded by
>    tejun.
> 
> Feel free to add my "Tested-by: Breno Leitao <leitao@debian.org>" tag.

thanks, I'll check this later today,

- Arnaldo

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

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found 2 potential
issue(s) to consider.

Critical: 0 · High: 0 · Medium: 1 · Low: 1

If you believe none of the issues are legitimate, please reply to each
issue of Medium severity or higher and explain why the AI is wrong.
If any of them are legitimate and you plan to respin, please let patchwork
know by including "pw-bot: cr" as a separate line at the end of your reply
(one such reply per series is enough).

- [Medium] The commit message of "bpf: tcp: bpf_tcp_ops_set_rcvlowat()
  missing from BTF with clang KCSAN" is cut off and missing required…
- [Low] The patch fixes a regression from 5f549c1e49f3 ("bpf: tcp: Add
  kfunc to adjust sk->sk_rcvlowat.") but has no Fixes: tag.

--

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

With clang and KCSAN, pahole drops bpf_tcp_ops_set_rcvlowat() from the
vmlinux BTF. This breaks the build when CONFIG_WERROR is set. When it
is not set, __bpf_tcp_ops_init() fails at boot. The patch works around
this by passing the clamped value straight to __tcp_set_rcvlowat()
instead of reassigning the rcvlowat parameter.

> 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

[Severity: Low]
Should this carry a Fixes: tag? 5f549c1e49f3 is only named in the prose.
That commit added the "if (rcvlowat < 0) rcvlowat = INT_MAX;"
reassignment in bpf_tcp_ops_set_rcvlowat(), which this patch rewrites.

Users can see this regression. When the kfunc set fails to register,
the chain in __bpf_tcp_ops_init() skips the struct_ops registration:

net/ipv4/bpf_tcp_ops.c:__bpf_tcp_ops_init() {
    ...
	ret = ret ?: register_btf_kfunc_id_set(BPF_PROG_TYPE_STRUCT_OPS,
					       &bpf_tcp_ops_set_rcvlowat_kfunc_id_set);
	ret = ret ?: register_bpf_struct_ops(&bpf_tcp_ops, bpf_tcp_ops);
    ...
}

The sched_ext workaround cited in this message, f2f095c87603, has a
Fixes: tag too. Would something like this work?

Fixes: 5f549c1e49f3 ("bpf: tcp: Add kfunc to adjust sk->sk_rcvlowat.")

[ ... ]

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

[ ... ]

> 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):

[Severity: Medium]
Was the commit message cut off here? It ends with a colon, and the
virtme test output it introduces never appears.

The message also says "discussed in [2]", but there is no [1], no
reference list and no Link: trailer, so the pahole discussion can't be
found from this commit.

There is also no Signed-off-by: line from the author. The DCO in
Documentation/process/submitting-patches.rst requires one, so the patch
can't be applied as posted.

The code change itself looks fine. Passing
"rcvlowat < 0 ? INT_MAX : rcvlowat" behaves the same as the old
reassignment.

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/au27Y9m78_3EH2v1%40gmail.com