Re: [bpf-next:master 2/5] net/core/bpf_ksock.c:221:18: sparse: sparse: symbol 'bpf_ksock_release_dtor' was not declared. Should it be static?

On Mon, Aug 17, 2026 at 05:39:52PM +0800, Jiayuan Chen wrote:
> 
> On 8/17/26 5:23 PM, Mahe Tardy wrote:
> > On Mon, Aug 17, 2026 at 12:36:48PM +0800, kernel test robot wrote:
> > > tree:   https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git master
> > > head:   c93cbdb13f995f87b5356329b3fe551c80bb482d
> > > commit: 7ae4eb14c5f9d9bf0e0feabeab206151b1280512 [2/5] bpf: Add ksock kfuncs
> > > config: nios2-randconfig-r112-20260817 (https://download.01.org/0day-ci/archive/20260817/[email protected]/config)
> > > compiler: nios2-linux-gcc (GCC) 11.5.0
> > > sparse: v0.6.5-rc1
> > > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260817/[email protected]/reproduce)
> > > 
> > > If you fix the issue in a separate patch/commit (i.e. not just a new version of
> > > the same patch/commit), kindly add following tags
> > > | Reported-by: kernel test robot <[email protected]>
> > > | Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
> > > 
> > > sparse warnings: (new ones prefixed by >>)
> > > > > net/core/bpf_ksock.c:221:18: sparse: sparse: symbol 'bpf_ksock_release_dtor' was not declared. Should it be static?
> > I'll add the 'static', it seems to make sense. I mostly copied this from
> > all the others examples with release_dtor functions which don't have
> > them but it seems for no good reason.
> 
> 
> I think we do not need 'static' actually, just like the doc says
> 
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/tree/Documentation/bpf/kfuncs.rst#n356
> 
> 
>     Note that kfuncs must not be declared ``static``. A kfunc can be called
> from a
>     BPF program ``*.c`` file outside the compilation unit that defines it,
> so its
>     externally visible name must remain available for BTF ID lookup.
> ``static``
>     linkage allows the compiler to rename the function, which can break this
>     BTF-based kfunc resolution. Further note that sparse may warn that an
> otherwise
>     unreferenced kfunc should be static. Such warnings should be ignored for
> kfunc
>     definitions.
> 
> 

Ah thanks for pointing that documentation, indeed I was looking at
examples of "__bpf_kfunc static" in the kernel code but it seems those
things are actually outdated and the paragraph you mention is up to date
since added last month[^1].

I assumed that since it was some kind of internal kfunc for the BPF
infra it would be okay but no, it still needs a stable name to resolves
the destructor´s address through kallsyms from the named retrieve via
the BTF id in btf_parse_kptr().

[^1]: https://lore.kernel.org/all/[email protected]/

> 
> 
> > > vim +/bpf_ksock_release_dtor +221 net/core/bpf_ksock.c
> > > 
> > >     220	
> > >   > 221	__bpf_kfunc void bpf_ksock_release_dtor(void *ks)
> > >     222	{
> > >     223		bpf_ksock_release(ks);
> > >     224	}
> > >     225	CFI_NOSEAL(bpf_ksock_release_dtor);
> > >     226	
> > > 
> > > --
> > > 0-DAY CI Kernel Test Service
> > > https://github.com/intel/lkp-tests/wiki