From: sashiko-bot@kernel.org
To: "Anton Protopopov" <a.s.protopopov@gmail.com>, bpf@vger.kernel.org
Subject: Re: [PATCH v2 bpf-next 07/18] scripts: Add LLVM plugin infrastructure
Date: Mon, 09 Nov 2026 17:45:01 +0000 [thread overview]
Message-ID: <sashiko-outbox-205331@kernel.org> (raw)
In-Reply-To: <20261109170550.141443-8-a.s.protopopov@gmail.com>
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
--
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-09 17:45 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 [this message]
2026-11-10 14:02 ` Anton Protopopov
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=sashiko-outbox-205331@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox