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