bpf: tcp: bpf_tcp_ops_set_rcvlowat() missing from BTF with clang KCSAN
Subsystems (3)
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):
net/ipv4/bpf_tcp_ops.c +3 -4
@@ -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/[email protected]/
[2] https://lore.kernel.org/all/[email protected]/
[email protected]
AI reviewThank you for your contribution! Sashiko AI review found 1 potential issue to consider: - [Low] bpf: tcp: missing Fixes trailer and truncated commit log --
Thank you for your contribution! Sashiko AI review found 1 potential issue to consider:
- [Low] bpf: tcp: missing Fixes trailer and truncated commit log --
commit f5456603019de81f20f04a8d77446db12563aeac
Author: Breno Leitao <[email protected]>
Quoted 29 lines
bpf: tcp:
bpf_tcp_ops_set_rcvlowat()missing from BTF with clang KCSANMy 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 kfuncbpf_tcp_ops_set_rcvlowatinbpf_tcp_ops_set_rcvlowat_kfunc_set
WARN:resolve_btfids: unresolved symbolbpf_tcp_ops_set_rcvlowat
Failed to generate BTF for vmlinux
Try to disableCONFIG_DEBUG_INFO_BTF
make[4]: *** [scripts/Makefile.vmlinux:72: vmlinux.unstripped] Error 1This is clang 22.1.3 and pahole 1.31 (current pahole master behaves the same), with
CONFIG_KCSAN=y,CONFIG_DEBUG_INFO_BTF=yandCONFIG_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 adjustsk->sk_rcvlowat."), and201a454df948("resolve_btfids: Fix the --fatal_warnings exit status") made the missing BTF fatal withCONFIG_WERROR. WithoutCONFIG_WERRORthe kernel builds, butbpf_tcp_opsis never registered:initcall
__bpf_tcp_ops_init+0x0/0x70returned -22 after 302 usecsThis seems similar to pahole behaviour
sched_exthit with a bool argument, discussed in [2] and worked around inf2f095c87603("sched_ext: Work around pahole 1.32 droppingscx_bpf_task_set_lazy_resched()from BTF").
Quoted 7 lines
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):
[Severity: Low]
This fixes a build and kfunc registration failure in bpf_tcp_ops_set_rcvlowat(). Should this include a Fixes tag?
Also, the commit message ends with a trailing colon and references [2] without a corresponding link, as if the trailers were truncated.
Signature · 1 line
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1
Thanks for the report !
Quoted 8 lines · 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 kfuncbpf_tcp_ops_set_rcvlowatinbpf_tcp_ops_set_rcvlowat_kfunc_set
WARN:resolve_btfids: unresolved symbolbpf_tcp_ops_set_rcvlowat
Failed to generate BTF for vmlinux
Try to disableCONFIG_DEBUG_INFO_BTF
make[4]: *** [scripts/Makefile.vmlinux:72: vmlinux.unstripped] Error 1
Has pahole fixed this issue?
Quoted 11 lines
This is clang 22.1.3 and pahole 1.31 (current pahole master behaves the same), with
CONFIG_KCSAN=y,CONFIG_DEBUG_INFO_BTF=yandCONFIG_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 adjustsk->sk_rcvlowat."), and201a454df948("resolve_btfids: Fix the --fatal_warnings exit status") made the missing BTF fatal withCONFIG_WERROR. WithoutCONFIG_WERRORthe kernel builds, butbpf_tcp_opsis never registered:
Quoted 6 lines
initcall
__bpf_tcp_ops_init+0x0/0x70returned -22 after 302 usecsThis seems similar to pahole behaviour
sched_exthit with a bool argument, discussed in [2] and worked around inf2f095c87603("sched_ext: Work around pahole 1.32 droppingscx_bpf_task_set_lazy_resched()from BTF").
This sets a bad example for future kfuncs, as if kfunc arguments must not be reassigned......
Quoted 32 lines
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):net/ipv4/bpf_tcp_ops.c +3
-4@@ -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/[email protected]/
[2] https://lore.kernel.org/all/[email protected]/
Quoted 15 lines · Jiayuan Chen
Thanks for the report !
Quoted 8 lines · 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 kfuncbpf_tcp_ops_set_rcvlowatinbpf_tcp_ops_set_rcvlowat_kfunc_set
WARN:resolve_btfids: unresolved symbolbpf_tcp_ops_set_rcvlowat
Failed to generate BTF for vmlinux
Try to disableCONFIG_DEBUG_INFO_BTF
make[4]: *** [scripts/Makefile.vmlinux:72: vmlinux.unstripped] Error 1
Quoted 1 line
Has pahole fixed this issue?
I don't think so, see the line below:
Quoted 2 lines
Quoted 2 lines
This is clang 22.1.3 and pahole 1.31 (current pahole master behaves the same),
Quoted 16 lines · Breno Leitao
Quoted 15 lines · Jiayuan Chen
Thanks for the report !
Quoted 8 lines · 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 kfuncbpf_tcp_ops_set_rcvlowatinbpf_tcp_ops_set_rcvlowat_kfunc_set
WARN:resolve_btfids: unresolved symbolbpf_tcp_ops_set_rcvlowat
Failed to generate BTF for vmlinux
Try to disableCONFIG_DEBUG_INFO_BTF
make[4]: *** [scripts/Makefile.vmlinux:72: vmlinux.unstripped] Error 1
Quoted 3 lines
Quoted 1 line
Has pahole fixed this issue?
I don't think so, see the line below:
Could you try this ?
---8<---
dwarf_loader.c +34 -14
@@ -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 coparameter__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<---
Quoted 17 lines · Kuniyuki Iwashima
Quoted 16 lines · Breno Leitao
Quoted 15 lines · Jiayuan Chen
Thanks for the report !
Quoted 8 lines · 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 kfuncbpf_tcp_ops_set_rcvlowatinbpf_tcp_ops_set_rcvlowat_kfunc_set
WARN:resolve_btfids: unresolved symbolbpf_tcp_ops_set_rcvlowat
Failed to generate BTF for vmlinux
Try to disableCONFIG_DEBUG_INFO_BTF
make[4]: *** [scripts/Makefile.vmlinux:72: vmlinux.unstripped] Error 1
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
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 <[email protected]>" tag.
--breno
Quoted 24 lines · Breno Leitao
Quoted 14 lines · Kuniyuki Iwashima
Quoted 13 lines · Breno Leitao
Quoted 12 lines · Jiayuan Chen
Thanks for the report !
Quoted 8 lines · 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 kfuncbpf_tcp_ops_set_rcvlowatinbpf_tcp_ops_set_rcvlowat_kfunc_set
WARN:resolve_btfids: unresolved symbolbpf_tcp_ops_set_rcvlowat
Failed to generate BTF for vmlinux
Try to disableCONFIG_DEBUG_INFO_BTF
make[4]: *** [scripts/Makefile.vmlinux:72: vmlinux.unstripped] Error 1Quoted 5 lines
Quoted 3 lines
Quoted 1 line
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:
Quoted 8 lines
- arm64 KCSAN,
CONFIG_WERROR=y: vmlinux links again,bpf_tcp_ops_set_rcvlowat()is back in BTF,__bpf_tcp_ops_init()returns 0, andprogs/tcp_autolowat.cfrom 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 <[email protected]>" tag.
thanks, I'll check this later today,
- Arnaldo
[email protected]
AI reviewThank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider.
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.
Quoted 7 lines
The kfunc came with
5f549c1e49f3("bpf: tcp: Add kfunc to adjustsk->sk_rcvlowat."), and201a454df948("resolve_btfids: Fix the --fatal_warnings exit status") made the missing BTF fatal withCONFIG_WERROR. WithoutCONFIG_WERRORthe kernel builds, butbpf_tcp_opsis never registered:initcall
__bpf_tcp_ops_init+0x0/0x70returned -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?
[ ... ]
Quoted 4 lines
This seems similar to pahole behaviour
sched_exthit with a bool argument, discussed in [2] and worked around inf2f095c87603("sched_ext: Work around pahole 1.32 droppingscx_bpf_task_set_lazy_resched()from BTF").
[ ... ]
Quoted 3 lines
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.
Signature · 1 line
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/au27Y9m78_3EH2v1%40gmail.com