[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?

[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?

[kernel test robot]

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/202608171256.McaD8rfl-lkp@intel.com/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/202608171256.McaD8rfl-lkp@intel.com/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 <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202608171256.McaD8rfl-lkp@intel.com/

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?

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

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?

[Mahe Tardy]

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/202608171256.McaD8rfl-lkp@intel.com/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/202608171256.McaD8rfl-lkp@intel.com/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 <lkp@intel.com>
> | Closes: https://lore.kernel.org/oe-kbuild-all/202608171256.McaD8rfl-lkp@intel.com/
> 
> 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.

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

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?

[Jiayuan Chen]

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/202608171256.McaD8rfl-lkp@intel.com/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/202608171256.McaD8rfl-lkp@intel.com/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 <lkp@intel.com>
>> | Closes: https://lore.kernel.org/oe-kbuild-all/202608171256.McaD8rfl-lkp@intel.com/
>>
>> 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.




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

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?

[Mahe Tardy]

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/202608171256.McaD8rfl-lkp@intel.com/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/202608171256.McaD8rfl-lkp@intel.com/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 <lkp@intel.com>
> > > | Closes: https://lore.kernel.org/oe-kbuild-all/202608171256.McaD8rfl-lkp@intel.com/
> > > 
> > > 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/20260626172026.7327-1-jp.kobryn@linux.dev/

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