All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mahe Tardy <mahe.tardy@gmail.com>
To: Jiayuan Chen <jiayuan.chen@linux.dev>
Cc: kernel test robot <lkp@intel.com>,
	oe-kbuild-all@lists.linux.dev,
	Daniel Borkmann <daniel@iogearbox.net>
Subject: 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?
Date: Mon, 17 Aug 2026 12:01:13 +0200	[thread overview]
Message-ID: <aoLb6bqvF6tA-riG@gmail.com> (raw)
In-Reply-To: <cd082ee1-efde-4cbe-b8f5-00d8aa2d072b@linux.dev>

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

      reply	other threads:[~2026-08-17 10:01 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-17  4:36 [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
2026-08-17  9:23 ` Mahe Tardy
2026-08-17  9:39   ` Jiayuan Chen
2026-08-17 10:01     ` Mahe Tardy [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aoLb6bqvF6tA-riG@gmail.com \
    --to=mahe.tardy@gmail.com \
    --cc=daniel@iogearbox.net \
    --cc=jiayuan.chen@linux.dev \
    --cc=lkp@intel.com \
    --cc=oe-kbuild-all@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.