Makefile | 16 ++++++++++++++++ arch/x86/xen/mmu_pv.c | 2 +- drivers/char/tpm/tpm-chip.c | 2 +- drivers/nvme/host/pci.c | 2 +- drivers/vfio/pci/virtio/legacy_io.c | 2 +- kernel/kcov.c | 2 +- kernel/rseq.c | 2 +- lib/Kconfig.debug | 21 +++++++++++++++++++++ lib/Makefile | 3 +++ mm/page_alloc.c | 2 +- 10 files changed, 47 insertions(+), 7 deletions(-)
This series introduces a new kernel configuration option NO_AUTO_INLINE,
which can be used to disable the automatic inlining of functions.
This will allow the function tracer to trace more functions
because it only traces functions that the compiler has not inlined.
Previous discussions can be found at
Link: https://lore.kernel.org/all/20181028130945.23581-3-changbin.du@gmail.com/
This patch depends on
[PATCH] drm/i915/pxp: fix undefined reference to
`intel_pxp_gsccs_is_ready_for_sessions'
which can be found at
https://lore.kernel.org/all/20250415090616.2649889-1-jani.nikula@intel.com/
as well as
[RFC PATCH 5/7] RDMA/hns: initialize db in update_srq_db()
which can be found at
https://lore.kernel.org/all/FF922C77946229B6+20250411105459.90782-5-chenlinxuan@uniontech.com/
Signed-off-by: Chen Linxuan <chenlinxuan@uniontech.com>
---
Changes in v3:
- Fix some modpost and objtool warnings
- Try support clang as Bart Van Assche suggested.
- Remove architecture depends as Bart Van Assche suggested.
- Link to v2: https://lore.kernel.org/r/20250416-noautoinline-v2-0-e69a2717530f@uniontech.com
Changes in v2:
- Resend via b4 to correct Message-ID and recipients.
- Update commit message following suggestions from Jarkko Sakkinen
- Link to v1: https://lore.kernel.org/r/31F42D8141CDD2D0+20250411105142.89296-1-chenlinxuan@uniontech.com
---
Chen Linxuan (4):
rseq: add __always_inline for rseq_kernel_fields
kcov: add __always_inline for canonicalize_ip
x86/xen: add __init for xen_pgd_walk
lib/Kconfig.debug: introduce CONFIG_NO_AUTO_INLINE
Winston Wen (4):
nvme: add __always_inline for nvme_pci_npages_prp
mm: add __always_inline for page_contains_unaccepted
vfio/virtio: add __always_inline for virtiovf_get_device_config_size
tpm: add __always_inline for tpm_is_hwrng_enabled
Makefile | 16 ++++++++++++++++
arch/x86/xen/mmu_pv.c | 2 +-
drivers/char/tpm/tpm-chip.c | 2 +-
drivers/nvme/host/pci.c | 2 +-
drivers/vfio/pci/virtio/legacy_io.c | 2 +-
kernel/kcov.c | 2 +-
kernel/rseq.c | 2 +-
lib/Kconfig.debug | 21 +++++++++++++++++++++
lib/Makefile | 3 +++
mm/page_alloc.c | 2 +-
10 files changed, 47 insertions(+), 7 deletions(-)
---
base-commit: ca91b9500108d4cf083a635c2e11c884d5dd20ea
change-id: 20250416-noautoinline-8e9b9e535452
Best regards,
--
Chen Linxuan <chenlinxuan@uniontech.com>
On Tue, Apr 29, 2025 at 12:06:04PM +0800, Chen Linxuan via B4 Relay wrote: > This series introduces a new kernel configuration option NO_AUTO_INLINE, > which can be used to disable the automatic inlining of functions. > > This will allow the function tracer to trace more functions > because it only traces functions that the compiler has not inlined. This still feels like a bad idea because it is extremely fragile.
On Tue, 29 Apr 2025 14:35:04 +0200 Christoph Hellwig wrote: > On Tue, Apr 29, 2025 at 12:06:04PM +0800, Chen Linxuan via B4 Relay wrote: > > > This series introduces a new kernel configuration option NO_AUTO_INLINE, > > which can be used to disable the automatic inlining of functions. > > > > This will allow the function tracer to trace more functions > > because it only traces functions that the compiler has not inlined. > > This still feels like a bad idea because it is extremely fragile. I'm not entirely sure if we're on the same page regarding this issue. However, I'd like to address the concerns about the fragility of NO_AUTO_INLINE. Maintaining NO_AUTO_INLINE to function correctly is indeed challenging, and I share some reservations about whether it should exist as a Kbuild option, which is precisely why this patch series is submitted as an RFC. I cannot even guarantee that I've addressed all existing issues in the current kernel repository with this patch series, as testing all possible compilation configurations is beyond my capabilities. Looking at the functions where I've added __always_inline in this patch series, nearly all of them require inlining specifically because their calls need to be resolved at compile time. The fundamental source of this fragility stems from the fact that compiler auto-inlining decisions aren't well-defined. If these functions were to change in the future for unrelated reasons - for example, if they became longer - and the compiler consequently decided not to automatically inline them, these same issues would surface regardless.
On Tue Apr 29, 2025 at 12:35 PM UTC, Christoph Hellwig wrote: > On Tue, Apr 29, 2025 at 12:06:04PM +0800, Chen Linxuan via B4 Relay wrote: >> This series introduces a new kernel configuration option NO_AUTO_INLINE, >> which can be used to disable the automatic inlining of functions. >> >> This will allow the function tracer to trace more functions >> because it only traces functions that the compiler has not inlined. > > This still feels like a bad idea because it is extremely fragile. Can you elaborate on that - does it introduce new fragility?
On Thu, May 01, 2025 at 02:19:47PM +0000, Brendan Jackman wrote: > On Tue Apr 29, 2025 at 12:35 PM UTC, Christoph Hellwig wrote: > > On Tue, Apr 29, 2025 at 12:06:04PM +0800, Chen Linxuan via B4 Relay wrote: > >> This series introduces a new kernel configuration option NO_AUTO_INLINE, > >> which can be used to disable the automatic inlining of functions. > >> > >> This will allow the function tracer to trace more functions > >> because it only traces functions that the compiler has not inlined. > > > > This still feels like a bad idea because it is extremely fragile. > > Can you elaborate on that - does it introduce new fragility? given it needs to sprinkle __always_inline around where it wasn't needed before, yeah. Also, why would you want this? function tracer is already too much output. Why would you want even more?
On Thu May 1, 2025 at 3:02 PM UTC, Peter Zijlstra wrote: > On Thu, May 01, 2025 at 02:19:47PM +0000, Brendan Jackman wrote: >> On Tue Apr 29, 2025 at 12:35 PM UTC, Christoph Hellwig wrote: >> > On Tue, Apr 29, 2025 at 12:06:04PM +0800, Chen Linxuan via B4 Relay wrote: >> >> This series introduces a new kernel configuration option NO_AUTO_INLINE, >> >> which can be used to disable the automatic inlining of functions. >> >> >> >> This will allow the function tracer to trace more functions >> >> because it only traces functions that the compiler has not inlined. >> > >> > This still feels like a bad idea because it is extremely fragile. >> >> Can you elaborate on that - does it introduce new fragility? > > given it needs to sprinkle __always_inline around where it wasn't needed > before, yeah. Right, I guess I just wouldn't have associated that with the word "fragility", but that's a reasonable complaint! > Also, why would you want this? function tracer is already too much > output. Why would you want even more? Yes, tracing every function is already too noisy, this would make it even more too-noisy, not sure "too noisy" -> "way too noisy" is a particularly meaningful degradation. Whereas enlarging the pool of functions that you can _optionally target_ for tracing, or nice reliable breakpoints in GDB, and disasm that's easier to mentally map back to C, seems like a helpful improvement for test builds. Personally I sometimes spam a bunch of `noinline` into code I'm debugging so this seems like a way to just slap that same thing on the whole tree without dirtying the code, right? Not that I have a strong opinion on the cost/benefit here, but the benefit seems nonzero to me.
On 5/1/25 8:22 AM, Brendan Jackman wrote: > Personally I sometimes spam a bunch of `noinline` into code > I'm debugging so this seems like a way to just slap that same thing on > the whole tree without dirtying the code, right? If this is for test builds only, has it been consider to add -fno-inline-functions as a local change in the top-level Makefile? Bart.
On Sun, May 4, 2025 at 3:14 AM Bart Van Assche <bvanassche@acm.org> wrote: > If this is for test builds only, has it been consider to add > -fno-inline-functions as a local change in the top-level Makefile? The issue here is that the current kernel cannot be compiled when these compiler options that reduce inlining behavior are added.
On Thu, May 01, 2025 at 03:22:55PM +0000, Brendan Jackman wrote: > Whereas enlarging the pool of functions that you can _optionally target_ > for tracing, or nice reliable breakpoints in GDB, and disasm that's > easier to mentally map back to C, seems like a helpful improvement for > test builds. Personally I sometimes spam a bunch of `noinline` into code > I'm debugging so this seems like a way to just slap that same thing on > the whole tree without dirtying the code, right? Dunno, I'm more of the printk school of debugging. Very rarely do I bother with GDB (so rare in fact that I have to look up how to even do this).
© 2016 - 2025 Red Hat, Inc.