From: Yonghong Song <yonghong.song@linux.dev>
To: Peter Zijlstra <peterz@infradead.org>,
Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: bpf <bpf@vger.kernel.org>, Alexei Starovoitov <ast@kernel.org>,
Andrii Nakryiko <andrii@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Kernel Team <kernel-team@fb.com>,
Martin KaFai Lau <martin.lau@kernel.org>,
Menglong Dong <menglong8.dong@gmail.com>,
Ihor Solodrai <ihor.solodrai@linux.dev>
Subject: Re: [PATCH bpf] bpf: Make migrate_{disable,enable} always inline if in header file
Date: Thu, 30 Oct 2025 08:18:53 -0700 [thread overview]
Message-ID: <ff3cb8dc-ef02-4e83-8a58-ad9b561e5213@linux.dev> (raw)
In-Reply-To: <20251030105318.GK4067720@noisy.programming.kicks-ass.net>
On 10/30/25 3:53 AM, Peter Zijlstra wrote:
> On Wed, Oct 29, 2025 at 06:13:21PM -0700, Alexei Starovoitov wrote:
>> On Wed, Oct 29, 2025 at 11:37 AM Yonghong Song <yonghong.song@linux.dev> wrote:
>>> With latest bpf/bpf-next tree and latest pahole master, I got the following
>>> build failure:
>>>
>>> $ make LLVM=1 -j
>>> ...
>>> LD vmlinux.o
>>> GEN .vmlinux.objs
>>> ...
>>> BTF .tmp_vmlinux1.btf.o
>>> ...
>>> AS .tmp_vmlinux2.kallsyms.o
>>> LD vmlinux.unstripped
>>> BTFIDS vmlinux.unstripped
>>> WARN: resolve_btfids: unresolved symbol migrate_enable
>>> WARN: resolve_btfids: unresolved symbol migrate_disable
>>> make[2]: *** [/home/yhs/work/bpf-next/scripts/Makefile.vmlinux:72: vmlinux.unstripped] Error 255
>>> make[2]: *** Deleting file 'vmlinux.unstripped'
>>> make[1]: *** [/home/yhs/work/bpf-next/Makefile:1242: vmlinux] Error 2
>>> make: *** [/home/yhs/work/bpf-next/Makefile:248: __sub-make] Error 2
>>>
>>> In pahole patch [1], if two functions having identical names but different
>>> addresses, then this function name is considered ambiguous and later on
>>> this function will not be added to vmlinux/module BTF.
>>>
>>> Commit 378b7708194f ("sched: Make migrate_{en,dis}able() inline") changed
>>> original global funcitons migrate_{enable,disable} to
>>> - in kernel/sched/core.c, migrate_{enable,disable} are global funcitons.
>>> - in other places, migrate_{enable,disable} may survive as static functions
>>> since they are marked as 'inline' in include/linux/sched.h and the
>>> 'inline' attribute does not garantee inlining.
>>>
>>> If I build with clang compiler (make LLVM=1 -j) (llvm21 and llvm22), I found
>>> there are four symbols for migrate_{enable,disable} respectively, three
>>> static functions and one global function. With the above pahole patch [1],
>>> migrate_{enable,disable} are not in vmlinux BTF and this will cause
>>> later resolve_btfids failure.
>>>
>>> Making migrate_{enable,disable} always inline in include/linux/sched.h
>>> can fix the problem.
>>>
>>> [1] https://lore.kernel.org/dwarves/79a329ef-9bb3-454e-9135-731f2fd51951@oracle.com/
>>>
>>> Fixes: 378b7708194f ("sched: Make migrate_{en,dis}able() inline")
>>> Cc: Menglong Dong <menglong8.dong@gmail.com>
>>> Cc: Ihor Solodrai <ihor.solodrai@linux.dev>
>>> Signed-off-by: Yonghong Song <yonghong.song@linux.dev>
>>> ---
>>> include/linux/sched.h | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/include/linux/sched.h b/include/linux/sched.h
>>> index cbb7340c5866..b469878de25c 100644
>>> --- a/include/linux/sched.h
>>> +++ b/include/linux/sched.h
>>> @@ -2407,12 +2407,12 @@ static inline void __migrate_enable(void) { }
>>> * be defined in kernel/sched/core.c.
>>> */
>>> #ifndef INSTANTIATE_EXPORTED_MIGRATE_DISABLE
>>> -static inline void migrate_disable(void)
>>> +static __always_inline void migrate_disable(void)
>>> {
>>> __migrate_disable();
>>> }
>>>
>>> -static inline void migrate_enable(void)
>>> +static __always_inline void migrate_enable(void)
>>> {
>>> __migrate_enable();
>>> }
>> Peter,
>>
>> Are you ok if we take this?
> Yes, but WTH would clang not inline this trivial function to begin with?
I checked asm codes with migrate_disable(). In the above cases,
__migrate_disable() is inlined and the function body of
migrate_disable() then becomes reasonably big. The caller of
migrate_disable() are ring_buffer_resize()*/*range_tree_set()/... which
are pretty big too.
next prev parent reply other threads:[~2025-10-30 15:19 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-29 18:36 [PATCH bpf] bpf: Make migrate_{disable,enable} always inline if in header file Yonghong Song
2025-10-30 1:00 ` Menglong Dong
2025-10-30 1:13 ` Alexei Starovoitov
2025-10-30 10:53 ` Peter Zijlstra
2025-10-30 15:18 ` Yonghong Song [this message]
2025-10-31 18:20 ` patchwork-bot+netdevbpf
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=ff3cb8dc-ef02-4e83-8a58-ad9b561e5213@linux.dev \
--to=yonghong.song@linux.dev \
--cc=alexei.starovoitov@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=ihor.solodrai@linux.dev \
--cc=kernel-team@fb.com \
--cc=martin.lau@kernel.org \
--cc=menglong8.dong@gmail.com \
--cc=peterz@infradead.org \
/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.