* [PATCH bpf-next] Fix undefined symbol references for module build post cnum changes
@ 2026-04-27 11:22 Alan Maguire
2026-04-27 12:08 ` Chengkaitao
2026-04-27 16:44 ` Eduard Zingerman
0 siblings, 2 replies; 6+ messages in thread
From: Alan Maguire @ 2026-04-27 11:22 UTC (permalink / raw)
To: ast, eddyz87
Cc: daniel, andrii, martin.lau, memxor, song, yonghong.song, jolsa,
bpf, Alan Maguire, Kaitao Cheng
Seeing the following on bpf-next:
DESCEND objtool
DESCEND bpf/resolve_btfids
INSTALL libsubcmd_headers
INSTALL libsubcmd_headers
MODPOST Module.symvers
ERROR: modpost: "cnum64_umin" [drivers/net/ethernet/netronome/nfp/nfp.ko] undefined!
ERROR: modpost: "cnum64_umax" [drivers/net/ethernet/netronome/nfp/nfp.ko] undefined!
make[2]: *** [scripts/Makefile.modpost:147: Module.symvers] Error 1
make[1]: *** [bpf-next/Makefile:2089: modpost] Error 2
make: *** [Makefile:248: __sub-make] Error 2
Further investigation suggests nfp indeed does pull in those symbols,
likely due to references in include/linux/bpf_verifier.h:
static inline s64 reg_smax(const struct bpf_reg_state *reg)
{
return cnum64_smax(reg->r64);
}
static inline u64 reg_umin(const struct bpf_reg_state *reg)
{
return cnum64_umin(reg->r64);
}
...
Export symbols for these references.
Reported-by: Kaitao Cheng <pilgrimtao@gmail.com>
Fixes: bbc631085503 ("bpf: replace min/max fields with struct cnum{32,64}")
Signed-off-by: Alan Maguire <alan.maguire@oracle.com>
---
kernel/bpf/cnum_defs.h | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/kernel/bpf/cnum_defs.h b/kernel/bpf/cnum_defs.h
index 3ebd8f723dbb..7d992ee6a8a4 100644
--- a/kernel/bpf/cnum_defs.h
+++ b/kernel/bpf/cnum_defs.h
@@ -6,6 +6,7 @@
#endif
#include <linux/cnum.h>
+#include <linux/kernel.h>
#include <linux/limits.h>
#include <linux/minmax.h>
#include <linux/compiler_types.h>
@@ -23,6 +24,7 @@ struct cnum_t FN(from_urange)(ut min, ut max)
{
return (struct cnum_t){ .base = min, .size = (ut)max - min };
}
+EXPORT_SYMBOL_GPL(FN(from_urange));
struct cnum_t FN(from_srange)(st min, st max)
{
@@ -31,6 +33,7 @@ struct cnum_t FN(from_srange)(st min, st max)
return (struct cnum_t){ .base = base, .size = size };
}
+EXPORT_SYMBOL_GPL(FN(from_srange));
/* True if this cnum represents two unsigned ranges. */
static inline bool FN(urange_overflow)(struct cnum_t cnum)
@@ -48,11 +51,13 @@ ut FN(umin)(struct cnum_t cnum)
{
return FN(urange_overflow)(cnum) ? 0 : cnum.base;
}
+EXPORT_SYMBOL_GPL(FN(umin));
ut FN(umax)(struct cnum_t cnum)
{
return FN(urange_overflow)(cnum) ? UT_MAX : cnum.base + cnum.size;
}
+EXPORT_SYMBOL_GPL(FN(umax));
/* True if this cnum represents two signed ranges. */
static inline bool FN(srange_overflow)(struct cnum_t cnum)
@@ -71,6 +76,7 @@ st FN(smin)(struct cnum_t cnum)
? ST_MIN
: min((st)cnum.base, (st)(cnum.base + cnum.size));
}
+EXPORT_SYMBOL_GPL(FN(smin));
st FN(smax)(struct cnum_t cnum)
{
@@ -78,6 +84,7 @@ st FN(smax)(struct cnum_t cnum)
? ST_MAX
: max((st)cnum.base, (st)(cnum.base + cnum.size));
}
+EXPORT_SYMBOL_GPL(FN(smax));
/*
* Returns a possibly empty intersection of cnums 'a' and 'b'.
--
2.39.3
^ permalink raw reply related [flat|nested] 6+ messages in thread* Re: [PATCH bpf-next] Fix undefined symbol references for module build post cnum changes
2026-04-27 11:22 [PATCH bpf-next] Fix undefined symbol references for module build post cnum changes Alan Maguire
@ 2026-04-27 12:08 ` Chengkaitao
2026-04-27 16:44 ` Eduard Zingerman
1 sibling, 0 replies; 6+ messages in thread
From: Chengkaitao @ 2026-04-27 12:08 UTC (permalink / raw)
To: Alan Maguire
Cc: ast, eddyz87, daniel, andrii, martin.lau, memxor, song,
yonghong.song, jolsa, bpf
On Mon, Apr 27, 2026 at 7:22 PM Alan Maguire <alan.maguire@oracle.com> wrote:
>
> Seeing the following on bpf-next:
>
> DESCEND objtool
> DESCEND bpf/resolve_btfids
> INSTALL libsubcmd_headers
> INSTALL libsubcmd_headers
> MODPOST Module.symvers
> ERROR: modpost: "cnum64_umin" [drivers/net/ethernet/netronome/nfp/nfp.ko] undefined!
> ERROR: modpost: "cnum64_umax" [drivers/net/ethernet/netronome/nfp/nfp.ko] undefined!
> make[2]: *** [scripts/Makefile.modpost:147: Module.symvers] Error 1
> make[1]: *** [bpf-next/Makefile:2089: modpost] Error 2
> make: *** [Makefile:248: __sub-make] Error 2
>
> Further investigation suggests nfp indeed does pull in those symbols,
> likely due to references in include/linux/bpf_verifier.h:
>
> static inline s64 reg_smax(const struct bpf_reg_state *reg)
> {
> return cnum64_smax(reg->r64);
> }
>
> static inline u64 reg_umin(const struct bpf_reg_state *reg)
> {
> return cnum64_umin(reg->r64);
> }
>
> ...
>
> Export symbols for these references.
>
> Reported-by: Kaitao Cheng <pilgrimtao@gmail.com>
> Fixes: bbc631085503 ("bpf: replace min/max fields with struct cnum{32,64}")
> Signed-off-by: Alan Maguire <alan.maguire@oracle.com>
> ---
> kernel/bpf/cnum_defs.h | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/kernel/bpf/cnum_defs.h b/kernel/bpf/cnum_defs.h
> index 3ebd8f723dbb..7d992ee6a8a4 100644
> --- a/kernel/bpf/cnum_defs.h
> +++ b/kernel/bpf/cnum_defs.h
> @@ -6,6 +6,7 @@
> #endif
>
> #include <linux/cnum.h>
> +#include <linux/kernel.h>
> #include <linux/limits.h>
> #include <linux/minmax.h>
> #include <linux/compiler_types.h>
> @@ -23,6 +24,7 @@ struct cnum_t FN(from_urange)(ut min, ut max)
> {
> return (struct cnum_t){ .base = min, .size = (ut)max - min };
> }
> +EXPORT_SYMBOL_GPL(FN(from_urange));
>
> struct cnum_t FN(from_srange)(st min, st max)
> {
> @@ -31,6 +33,7 @@ struct cnum_t FN(from_srange)(st min, st max)
>
> return (struct cnum_t){ .base = base, .size = size };
> }
> +EXPORT_SYMBOL_GPL(FN(from_srange));
>
> /* True if this cnum represents two unsigned ranges. */
> static inline bool FN(urange_overflow)(struct cnum_t cnum)
> @@ -48,11 +51,13 @@ ut FN(umin)(struct cnum_t cnum)
> {
> return FN(urange_overflow)(cnum) ? 0 : cnum.base;
> }
> +EXPORT_SYMBOL_GPL(FN(umin));
>
> ut FN(umax)(struct cnum_t cnum)
> {
> return FN(urange_overflow)(cnum) ? UT_MAX : cnum.base + cnum.size;
> }
> +EXPORT_SYMBOL_GPL(FN(umax));
>
> /* True if this cnum represents two signed ranges. */
> static inline bool FN(srange_overflow)(struct cnum_t cnum)
> @@ -71,6 +76,7 @@ st FN(smin)(struct cnum_t cnum)
> ? ST_MIN
> : min((st)cnum.base, (st)(cnum.base + cnum.size));
> }
> +EXPORT_SYMBOL_GPL(FN(smin));
>
> st FN(smax)(struct cnum_t cnum)
> {
> @@ -78,6 +84,7 @@ st FN(smax)(struct cnum_t cnum)
> ? ST_MAX
> : max((st)cnum.base, (st)(cnum.base + cnum.size));
> }
> +EXPORT_SYMBOL_GPL(FN(smax));
>
> /*
> * Returns a possibly empty intersection of cnums 'a' and 'b'.
> --
> 2.39.3
>
LGFM.
--
Yours,
Chengkaitao
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH bpf-next] Fix undefined symbol references for module build post cnum changes
2026-04-27 11:22 [PATCH bpf-next] Fix undefined symbol references for module build post cnum changes Alan Maguire
2026-04-27 12:08 ` Chengkaitao
@ 2026-04-27 16:44 ` Eduard Zingerman
2026-04-27 17:07 ` Eduard Zingerman
1 sibling, 1 reply; 6+ messages in thread
From: Eduard Zingerman @ 2026-04-27 16:44 UTC (permalink / raw)
To: Alan Maguire, ast
Cc: daniel, andrii, martin.lau, memxor, song, yonghong.song, jolsa,
bpf, Kaitao Cheng
On Mon, 2026-04-27 at 12:22 +0100, Alan Maguire wrote:
> Seeing the following on bpf-next:
>
> DESCEND objtool
> DESCEND bpf/resolve_btfids
> INSTALL libsubcmd_headers
> INSTALL libsubcmd_headers
> MODPOST Module.symvers
> ERROR: modpost: "cnum64_umin" [drivers/net/ethernet/netronome/nfp/nfp.ko] undefined!
> ERROR: modpost: "cnum64_umax" [drivers/net/ethernet/netronome/nfp/nfp.ko] undefined!
> make[2]: *** [scripts/Makefile.modpost:147: Module.symvers] Error 1
> make[1]: *** [bpf-next/Makefile:2089: modpost] Error 2
> make: *** [Makefile:248: __sub-make] Error 2
>
> Further investigation suggests nfp indeed does pull in those symbols,
> likely due to references in include/linux/bpf_verifier.h:
>
> static inline s64 reg_smax(const struct bpf_reg_state *reg)
> {
> return cnum64_smax(reg->r64);
> }
>
> static inline u64 reg_umin(const struct bpf_reg_state *reg)
> {
> return cnum64_umin(reg->r64);
> }
>
> ...
>
> Export symbols for these references.
>
> Reported-by: Kaitao Cheng <pilgrimtao@gmail.com>
> Fixes: bbc631085503 ("bpf: replace min/max fields with struct cnum{32,64}")
> Signed-off-by: Alan Maguire <alan.maguire@oracle.com>
> ---
Hi Alan,
thank you for the fix, apologies for breaking this.
Acked-by: Eduard Zingerman <eddyz87@gmail.com>
[...]
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH bpf-next] Fix undefined symbol references for module build post cnum changes
2026-04-27 16:44 ` Eduard Zingerman
@ 2026-04-27 17:07 ` Eduard Zingerman
2026-04-27 17:11 ` Alexei Starovoitov
0 siblings, 1 reply; 6+ messages in thread
From: Eduard Zingerman @ 2026-04-27 17:07 UTC (permalink / raw)
To: Alan Maguire, ast
Cc: daniel, andrii, martin.lau, memxor, song, yonghong.song, jolsa,
bpf, Kaitao Cheng
On Mon, 2026-04-27 at 09:44 -0700, Eduard Zingerman wrote:
> On Mon, 2026-04-27 at 12:22 +0100, Alan Maguire wrote:
> > Seeing the following on bpf-next:
> >
> > DESCEND objtool
> > DESCEND bpf/resolve_btfids
> > INSTALL libsubcmd_headers
> > INSTALL libsubcmd_headers
> > MODPOST Module.symvers
> > ERROR: modpost: "cnum64_umin" [drivers/net/ethernet/netronome/nfp/nfp.ko] undefined!
> > ERROR: modpost: "cnum64_umax" [drivers/net/ethernet/netronome/nfp/nfp.ko] undefined!
> > make[2]: *** [scripts/Makefile.modpost:147: Module.symvers] Error 1
> > make[1]: *** [bpf-next/Makefile:2089: modpost] Error 2
> > make: *** [Makefile:248: __sub-make] Error 2
> >
> > Further investigation suggests nfp indeed does pull in those symbols,
> > likely due to references in include/linux/bpf_verifier.h:
> >
> > static inline s64 reg_smax(const struct bpf_reg_state *reg)
> > {
> > return cnum64_smax(reg->r64);
> > }
> >
> > static inline u64 reg_umin(const struct bpf_reg_state *reg)
> > {
> > return cnum64_umin(reg->r64);
> > }
> >
> > ...
> >
> > Export symbols for these references.
> >
> > Reported-by: Kaitao Cheng <pilgrimtao@gmail.com>
> > Fixes: bbc631085503 ("bpf: replace min/max fields with struct cnum{32,64}")
> > Signed-off-by: Alan Maguire <alan.maguire@oracle.com>
> > ---
>
> Hi Alan,
>
> thank you for the fix, apologies for breaking this.
>
> Acked-by: Eduard Zingerman <eddyz87@gmail.com>
However, Alexei raises a valid question.
Netronome code uses the following accessors:
- cnum{32,64}_reg_umin
- cnum{32,64}_reg_umax
However, this patch also exports the following on top:
- cnum{32,64}_from_{urange,srange}
- cnum{32,64}_reg_smin
- cnum{32,64}_reg_smax
Why export extra accessors?
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH bpf-next] Fix undefined symbol references for module build post cnum changes
2026-04-27 17:07 ` Eduard Zingerman
@ 2026-04-27 17:11 ` Alexei Starovoitov
2026-04-29 17:10 ` Alan Maguire
0 siblings, 1 reply; 6+ messages in thread
From: Alexei Starovoitov @ 2026-04-27 17:11 UTC (permalink / raw)
To: Eduard Zingerman
Cc: Alan Maguire, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Kumar Kartikeya Dwivedi,
Song Liu, Yonghong Song, Jiri Olsa, bpf, Kaitao Cheng
On Mon, Apr 27, 2026 at 6:07 PM Eduard Zingerman <eddyz87@gmail.com> wrote:
>
> On Mon, 2026-04-27 at 09:44 -0700, Eduard Zingerman wrote:
> > On Mon, 2026-04-27 at 12:22 +0100, Alan Maguire wrote:
> > > Seeing the following on bpf-next:
> > >
> > > DESCEND objtool
> > > DESCEND bpf/resolve_btfids
> > > INSTALL libsubcmd_headers
> > > INSTALL libsubcmd_headers
> > > MODPOST Module.symvers
> > > ERROR: modpost: "cnum64_umin" [drivers/net/ethernet/netronome/nfp/nfp.ko] undefined!
> > > ERROR: modpost: "cnum64_umax" [drivers/net/ethernet/netronome/nfp/nfp.ko] undefined!
> > > make[2]: *** [scripts/Makefile.modpost:147: Module.symvers] Error 1
> > > make[1]: *** [bpf-next/Makefile:2089: modpost] Error 2
> > > make: *** [Makefile:248: __sub-make] Error 2
> > >
> > > Further investigation suggests nfp indeed does pull in those symbols,
> > > likely due to references in include/linux/bpf_verifier.h:
> > >
> > > static inline s64 reg_smax(const struct bpf_reg_state *reg)
> > > {
> > > return cnum64_smax(reg->r64);
> > > }
> > >
> > > static inline u64 reg_umin(const struct bpf_reg_state *reg)
> > > {
> > > return cnum64_umin(reg->r64);
> > > }
> > >
> > > ...
> > >
> > > Export symbols for these references.
> > >
> > > Reported-by: Kaitao Cheng <pilgrimtao@gmail.com>
> > > Fixes: bbc631085503 ("bpf: replace min/max fields with struct cnum{32,64}")
> > > Signed-off-by: Alan Maguire <alan.maguire@oracle.com>
> > > ---
> >
> > Hi Alan,
> >
> > thank you for the fix, apologies for breaking this.
> >
> > Acked-by: Eduard Zingerman <eddyz87@gmail.com>
>
> However, Alexei raises a valid question.
> Netronome code uses the following accessors:
> - cnum{32,64}_reg_umin
> - cnum{32,64}_reg_umax
>
> However, this patch also exports the following on top:
> - cnum{32,64}_from_{urange,srange}
> - cnum{32,64}_reg_smin
> - cnum{32,64}_reg_smax
>
> Why export extra accessors?
I left only 2 while applying and rewrote commit log.
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH bpf-next] Fix undefined symbol references for module build post cnum changes
2026-04-27 17:11 ` Alexei Starovoitov
@ 2026-04-29 17:10 ` Alan Maguire
0 siblings, 0 replies; 6+ messages in thread
From: Alan Maguire @ 2026-04-29 17:10 UTC (permalink / raw)
To: Alexei Starovoitov, Eduard Zingerman
Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Kumar Kartikeya Dwivedi, Song Liu,
Yonghong Song, Jiri Olsa, bpf, Kaitao Cheng
On 27/04/2026 18:11, Alexei Starovoitov wrote:
> On Mon, Apr 27, 2026 at 6:07 PM Eduard Zingerman <eddyz87@gmail.com> wrote:
>>
>> On Mon, 2026-04-27 at 09:44 -0700, Eduard Zingerman wrote:
>>> On Mon, 2026-04-27 at 12:22 +0100, Alan Maguire wrote:
>>>> Seeing the following on bpf-next:
>>>>
>>>> DESCEND objtool
>>>> DESCEND bpf/resolve_btfids
>>>> INSTALL libsubcmd_headers
>>>> INSTALL libsubcmd_headers
>>>> MODPOST Module.symvers
>>>> ERROR: modpost: "cnum64_umin" [drivers/net/ethernet/netronome/nfp/nfp.ko] undefined!
>>>> ERROR: modpost: "cnum64_umax" [drivers/net/ethernet/netronome/nfp/nfp.ko] undefined!
>>>> make[2]: *** [scripts/Makefile.modpost:147: Module.symvers] Error 1
>>>> make[1]: *** [bpf-next/Makefile:2089: modpost] Error 2
>>>> make: *** [Makefile:248: __sub-make] Error 2
>>>>
>>>> Further investigation suggests nfp indeed does pull in those symbols,
>>>> likely due to references in include/linux/bpf_verifier.h:
>>>>
>>>> static inline s64 reg_smax(const struct bpf_reg_state *reg)
>>>> {
>>>> return cnum64_smax(reg->r64);
>>>> }
>>>>
>>>> static inline u64 reg_umin(const struct bpf_reg_state *reg)
>>>> {
>>>> return cnum64_umin(reg->r64);
>>>> }
>>>>
>>>> ...
>>>>
>>>> Export symbols for these references.
>>>>
>>>> Reported-by: Kaitao Cheng <pilgrimtao@gmail.com>
>>>> Fixes: bbc631085503 ("bpf: replace min/max fields with struct cnum{32,64}")
>>>> Signed-off-by: Alan Maguire <alan.maguire@oracle.com>
>>>> ---
>>>
>>> Hi Alan,
>>>
>>> thank you for the fix, apologies for breaking this.
>>>
>>> Acked-by: Eduard Zingerman <eddyz87@gmail.com>
>>
>> However, Alexei raises a valid question.
>> Netronome code uses the following accessors:
>> - cnum{32,64}_reg_umin
>> - cnum{32,64}_reg_umax
>>
>> However, this patch also exports the following on top:
>> - cnum{32,64}_from_{urange,srange}
>> - cnum{32,64}_reg_smin
>> - cnum{32,64}_reg_smax
>>
>> Why export extra accessors?
>
> I left only 2 while applying and rewrote commit log.
Yep, I just added the accessors as they are potentially available to consumers
via bpf_verifier.h. No actual users today though as far as I could see. Thanks!
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2026-04-29 17:11 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-04-27 11:22 [PATCH bpf-next] Fix undefined symbol references for module build post cnum changes Alan Maguire
2026-04-27 12:08 ` Chengkaitao
2026-04-27 16:44 ` Eduard Zingerman
2026-04-27 17:07 ` Eduard Zingerman
2026-04-27 17:11 ` Alexei Starovoitov
2026-04-29 17:10 ` Alan Maguire
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox