Linux-mm Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Roman Gushchin <roman.gushchin@linux.dev>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: JP Kobryn <jp.kobryn@linux.dev>,
	 Shakeel Butt <shakeel.butt@linux.dev>,
	Andrew Morton <akpm@linux-foundation.org>,
	 Alexei Starovoitov <ast@kernel.org>,  bpf <bpf@vger.kernel.org>,
	 linux-mm <linux-mm@kvack.org>,
	 LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mm/bpf_memcontrol: mark BPF memcg kfuncs static
Date: Wed, 17 Jun 2026 22:31:38 +0000	[thread overview]
Message-ID: <7ia4cxxosss5.fsf@castle.c.googlers.com> (raw)
In-Reply-To: <CAADnVQJ=q7hJkt=ekLD_a5KjJ_+icdwgsY61rujjLMKAKByvWw@mail.gmail.com> (Alexei Starovoitov's message of "Wed, 17 Jun 2026 14:06:31 -0700")

Alexei Starovoitov <alexei.starovoitov@gmail.com> writes:

> On Wed, Jun 17, 2026 at 1:22 PM JP Kobryn <jp.kobryn@linux.dev> wrote:
>>
>> The kfuncs in bpf_memcontrol.c are not called by in-kernel C code. They are
>> only referenced by BPF programs and resolved through BTF.
>>
>> Since no external linkage is needed, mark these functions static.
>>
>> Fixes: 5904db9891f8 ("mm: introduce BPF kfuncs to deal with memcg pointers")
>> Fixes: 5c7db3239c9f ("mm: introduce bpf_get_root_mem_cgroup() BPF kfunc")
>> Fixes: 99430ab8b804 ("mm: introduce BPF kfuncs to access memcg statistics and events")
>> Reported-by: kernel test robot <lkp@intel.com>
>> Closes: https://lore.kernel.org/oe-kbuild-all/202606150332.Xy4Egd9s-lkp@intel.com/
>> Signed-off-by: JP Kobryn <jp.kobryn@linux.dev>
>> ---
>>  mm/bpf_memcontrol.c | 21 +++++++++++----------
>>  1 file changed, 11 insertions(+), 10 deletions(-)
>>
>> diff --git a/mm/bpf_memcontrol.c b/mm/bpf_memcontrol.c
>> index 716df49d7647..eff79bb2c758 100644
>> --- a/mm/bpf_memcontrol.c
>> +++ b/mm/bpf_memcontrol.c
>> @@ -20,7 +20,7 @@ __bpf_kfunc_start_defs();
>>   *
>>   * Return: A pointer to the root memory cgroup.
>>   */
>> -__bpf_kfunc struct mem_cgroup *bpf_get_root_mem_cgroup(void)
>> +__bpf_kfunc static struct mem_cgroup *bpf_get_root_mem_cgroup(void)
>
> sashiko disappoints. It couldn't notice that kfuncs should not be static.
> We have few "__bpf_kfunc static" in net/ipv4/
> that work by sort-of "luck", since their addresses are taken.
>
> In general kfuncs cannot be declared static.

It seems like it thought hard on it but failed based on the existing
code and a bit vague documentation in Documentation/bpf/kfuncs.rst:

  kfunc definitions should also always be annotated with the ``__bpf_kfunc``
  macro. This prevents issues such as the compiler inlining the kfunc if it's a
  static kernel function, or the function ...

So it reads like bpf kfuncs can be static.

This is the reasoning from the logs (a dismissed concern, to be precise):
{
      "type": "Dead Code / Linker Error",

      "description": "Marking kfuncs as static could cause the compiler
      to optimize them away, breaking BPF verifier BTF resolution.",

      "reasoning": "The patch adds `static` to multiple `__bpf_kfunc`
      annotated functions that are not called anywhere in C
      code. Normally, a compiler would remove unused static functions or
      fail to expose them in object files, which could prevent the BTF
      ID generation logic (`resolve_btfids`) from finding them. However,
      the `__bpf_kfunc` macro expands to include `__used` and
      `__retain`, which strictly instructs the compiler and linker to
      preserve the functions in the object file regardless of
      usage. Additionally, `resolve_btfids` and `BTF_ID_FLAGS`
      successfully parse and resolve `STB_LOCAL` static symbols, making
      this change completely safe and correct.",

      "locations": [
        {
          "file": "mm/bpf_memcontrol.c",
          "function_or_symbol": null,
          "line_range": null,
          "why_this_location_matters": "This applies to all the
          functions modified by the patch."
        }
      ]
    }


Thanks


      reply	other threads:[~2026-06-17 22:31 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-17 20:21 [PATCH] mm/bpf_memcontrol: mark BPF memcg kfuncs static JP Kobryn
2026-06-17 21:06 ` Alexei Starovoitov
2026-06-17 22:31   ` Roman Gushchin [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=7ia4cxxosss5.fsf@castle.c.googlers.com \
    --to=roman.gushchin@linux.dev \
    --cc=akpm@linux-foundation.org \
    --cc=alexei.starovoitov@gmail.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=jp.kobryn@linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=shakeel.butt@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox