From: Anton Protopopov <a.s.protopopov@gmail.com>
To: sashiko-reviews@lists.linux.dev
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH v2 bpf-next 07/18] scripts: Add LLVM plugin infrastructure
Date: Tue, 10 Nov 2026 14:02:50 +0000 [thread overview]
Message-ID: <avMkCh9LLezKS151@mail.gmail.com> (raw)
In-Reply-To: <sashiko-outbox-205331@kernel.org>
On 26/11/09 05:45PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential
> issues to consider:
> - [Low] riscv: pi: filter out LLVM_PLUGINS_CFLAGS from KBUILD_CFLAGS
> - [Low] vdso: avoid stripping LLVM_PLUGINS_CFLAGS from kernel objects
> --
no, riscv is not supported yet, vdso is not target for fmodret
> commit 072fb07f8d2d07b80e87b0ea8e05cc60c466504e
> Author: Anton Protopopov <a.s.protopopov@gmail.com>
>
> scripts: Add LLVM plugin infrastructure
>
> This commit adds Kbuild and Kconfig infrastructure for building and loading
> LLVM IR pass plugins with -fpass-plugin, and excludes LLVM_PLUGINS_CFLAGS
> from vDSO, EFI stub, and early boot builds.
>
> > diff --git a/arch/arm64/kernel/pi/Makefile b/arch/arm64/kernel/pi/Makefile
> > index a273ab5af805c..5813bb75c9925 100644
> > --- a/arch/arm64/kernel/pi/Makefile
> > +++ b/arch/arm64/kernel/pi/Makefile
> > @@ -10,6 +10,7 @@ KBUILD_CFLAGS := $(subst $(CC_FLAGS_FTRACE),,$(KBUILD_CFLAGS)) -fpie \
> > -D__DISABLE_EXPORTS -ffreestanding -D__NO_FORTIFY \
> > -fno-asynchronous-unwind-tables -fno-unwind-tables \
> > $(CONFIG_CC_OPT_NO_ADDRSIG)
> > +KBUILD_CFLAGS := $(filter-out $(LLVM_PLUGINS_CFLAGS),$(KBUILD_CFLAGS))
>
> [Severity: Low]
> Should arch/riscv/kernel/pi/Makefile also filter out $(LLVM_PLUGINS_CFLAGS)
> from KBUILD_CFLAGS?
>
> Like arch/arm64/kernel/pi/Makefile, it compiles pre-MMU position-independent
> early boot objects with -fpie and -ffreestanding, filters out
> CC_FLAGS_FTRACE and CC_FLAGS_LTO, and prefixes symbols with __pi_ via
> objcopy. Leaving LLVM_PLUGINS_CFLAGS enabled there can break symbol
> confinement or introduce absolute addresses before the MMU and relocations
> are active.
>
> [ ... ]
>
> > diff --git a/lib/vdso/Makefile.include b/lib/vdso/Makefile.include
> > index cedbf15f80874..848d58296ba23 100644
> > --- a/lib/vdso/Makefile.include
> > +++ b/lib/vdso/Makefile.include
> > @@ -1,5 +1,8 @@
> > # SPDX-License-Identifier: GPL-2.0
> >
> > +# vDSO code executes outside the kernel.
> > +KBUILD_CFLAGS := $(filter-out $(LLVM_PLUGINS_CFLAGS),$(KBUILD_CFLAGS))
> > +
> > GENERIC_VDSO_MK_PATH := $(abspath $(lastword $(MAKEFILE_LIST)))
> > GENERIC_VDSO_DIR := $(dir $(GENERIC_VDSO_MK_PATH))
>
> [Severity: Low]
> Does stripping $(LLVM_PLUGINS_CFLAGS) from the directory-wide KBUILD_CFLAGS
> here also drop LLVM plugins from standard in-kernel objects built in those
> directories?
>
> Makefiles that include lib/vdso/Makefile.include also build obj-y kernel
> objects linked into vmlinux, such as arch/sparc/vdso/vma.o and the
> vdso*-image.o targets in arch/x86/entry/vdso/common/Makefile.include,
> arch/sparc/vdso/Makefile, and arch/mips/vdso/Makefile. Those Makefiles
> scope $(GCC_PLUGINS_CFLAGS) removal to $(vobjs) (as this patch does for
> arch/x86/um/vdso/Makefile), whereas modifying KBUILD_CFLAGS unconditionally
> in lib/vdso/Makefile.include prevents enabled LLVM plugins from running on
> the in-kernel objects and drops their <generated/llvm-plugins.h> rebuild
> dependency.
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20261109170550.141443-1-a.s.protopopov@gmail.com?part=7
next prev parent reply other threads:[~2026-11-10 13:51 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-09 17:05 [PATCH v2 bpf-next 00/18] Auto-detect BPF fmodret targets Anton Protopopov
2026-11-09 17:05 ` [PATCH v2 bpf-next 01/18] bpf: Add BTF ID sets for fmod_ret targets Anton Protopopov
2026-11-09 17:42 ` bot+bpf-ci
2026-11-10 14:00 ` Anton Protopopov
2026-11-09 17:05 ` [PATCH v2 bpf-next 02/18] bpf: Add a btf_id_set8_entry helper Anton Protopopov
2026-11-09 17:05 ` [PATCH v2 bpf-next 03/18] bpf: Build fmod_ret target sets from BTF decl tags Anton Protopopov
2026-11-09 17:05 ` [PATCH v2 bpf-next 04/18] selftests/bpf: Declare bpf_fentry_test1 in tracing tests Anton Protopopov
2026-11-09 17:05 ` [PATCH v2 bpf-next 05/18] bpf: Declare fmod_ret targets with BTF_FMODRET sets Anton Protopopov
2026-11-09 17:05 ` [PATCH v2 bpf-next 06/18] selftests/bpf: Test fmod_ret BTF decl tags and attach permission Anton Protopopov
2026-11-09 17:05 ` [PATCH v2 bpf-next 07/18] scripts: Add LLVM plugin infrastructure Anton Protopopov
2026-11-09 17:45 ` sashiko-bot
2026-11-10 14:02 ` Anton Protopopov [this message]
2026-11-09 17:05 ` [PATCH v2 bpf-next 08/18] bpf: Add the bpf_scan_ir LLVM plugin Anton Protopopov
2026-11-09 17:05 ` [PATCH v2 bpf-next 09/18] bpf: Find fmod_ret candidates in bpf_scan_ir Anton Protopopov
2026-11-09 17:05 ` [PATCH v2 bpf-next 10/18] bpf: Allow writes to private stack objects " Anton Protopopov
2026-11-09 17:05 ` [PATCH v2 bpf-next 11/18] bpf: Follow PHIs " Anton Protopopov
2026-11-09 17:42 ` bot+bpf-ci
2026-11-10 14:04 ` Anton Protopopov
2026-11-09 17:05 ` [PATCH v2 bpf-next 12/18] bpf: Follow integer casts " Anton Protopopov
2026-11-09 17:05 ` [PATCH v2 bpf-next 13/18] bpf: Check the return values of fmod_ret programs on found targets Anton Protopopov
2026-11-09 17:42 ` bot+bpf-ci
2026-11-10 14:30 ` Anton Protopopov
2026-11-09 17:05 ` [PATCH v2 bpf-next 14/18] bpf: Require the JIT for fmod_ret programs on found 64-bit targets Anton Protopopov
2026-11-09 17:05 ` [PATCH v2 bpf-next 15/18] resolve_btfids: Tag fmod_ret candidates as targets Anton Protopopov
2026-11-09 17:42 ` bot+bpf-ci
2026-11-10 15:17 ` Anton Protopopov
2026-11-09 18:13 ` sashiko-bot
2026-11-10 15:19 ` Anton Protopopov
2026-11-09 17:05 ` [PATCH v2 bpf-next 16/18] selftests/bpf: Test fmod_ret candidates found by bpf_scan_ir Anton Protopopov
2026-11-09 17:05 ` [PATCH v2 bpf-next 17/18] selftests/bpf: Enable bpf_scan_ir in the config Anton Protopopov
2026-11-09 17:05 ` [PATCH v2 bpf-next 18/18] bpftool: List and show fmod_ret targets Anton Protopopov
2026-11-09 17:42 ` bot+bpf-ci
2026-11-10 15:30 ` Anton Protopopov
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=avMkCh9LLezKS151@mail.gmail.com \
--to=a.s.protopopov@gmail.com \
--cc=bpf@vger.kernel.org \
--cc=sashiko-reviews@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.