* [PATCH v4 0/7] Unload linux/kernel.h
@ 2025-12-25 17:09 Yury Norov (NVIDIA)
2025-12-25 17:09 ` [PATCH v4 1/7] kernel.h: drop STACK_MAGIC macro Yury Norov (NVIDIA)
` (6 more replies)
0 siblings, 7 replies; 28+ messages in thread
From: Yury Norov (NVIDIA) @ 2025-12-25 17:09 UTC (permalink / raw)
To: Steven Rostedt, Andrew Morton, Masami Hiramatsu,
Mathieu Desnoyers, Andy Shevchenko, Christophe Leroy,
Randy Dunlap, Ingo Molnar, Jani Nikula, Joonas Lahtinen,
David Laight, Petr Pavlu, Andi Shyti, Rodrigo Vivi,
Tvrtko Ursulin, Daniel Gomez, Greg Kroah-Hartman,
Rafael J. Wysocki, Danilo Krummrich, linux-kernel, intel-gfx,
dri-devel, linux-modules, linux-trace-kernel
Cc: Yury Norov (NVIDIA)
kernel.h hosts declarations that can be placed better. This series
decouples kernel.h with some explicit and implicit dependencies; also,
moves tracing functionality to a new independent header.
My local build testing shows ~2% performance improvement for GCC +
Ubuntu x86_64/localyesconfig.
v1: https://lore.kernel.org/all/20251129195304.204082-1-yury.norov@gmail.com/
v2: https://lore.kernel.org/all/20251203162329.280182-1-yury.norov@gmail.com/
v3: https://lore.kernel.org/all/20251205175237.242022-1-yury.norov@gmail.com/
v4:
- drop kernel.h dependency on linux/instruction_pointer.h (new patch #4);
- drop trace_printk.h dependency on string.h (new patch #5 - Steven);
- drop kernel.h dependency on trace_printk.h (new patch #7);
- explicitly tested CONFIG_FORTIFY x86_64 build with no issues.
0-DAY CI Kernel Test Service:
alpha allnoconfig gcc-15.1.0
alpha allyesconfig gcc-15.1.0
alpha defconfig gcc-15.1.0
arc allmodconfig clang-16
arc allmodconfig gcc-15.1.0
arc allnoconfig gcc-15.1.0
arc allyesconfig clang-22
arc allyesconfig gcc-15.1.0
arc defconfig gcc-15.1.0
arc randconfig-001-20251225 gcc-11.5.0
arc randconfig-002-20251225 gcc-11.5.0
arm allnoconfig clang-22
arm allnoconfig gcc-15.1.0
arm allyesconfig clang-16
arm allyesconfig gcc-15.1.0
arm defconfig gcc-15.1.0
arm exynos_defconfig gcc-15.1.0
arm randconfig-001-20251225 gcc-11.5.0
arm randconfig-002-20251225 gcc-11.5.0
arm randconfig-003-20251225 gcc-11.5.0
arm randconfig-004-20251225 gcc-11.5.0
arm spitz_defconfig gcc-15.1.0
arm64 allmodconfig clang-19
arm64 allmodconfig clang-22
arm64 allnoconfig gcc-15.1.0
arm64 defconfig gcc-15.1.0
arm64 randconfig-001-20251225 clang-18
arm64 randconfig-001-20251225 gcc-11.5.0
arm64 randconfig-002-20251225 gcc-11.5.0
arm64 randconfig-002-20251225 gcc-12.5.0
arm64 randconfig-003-20251225 clang-22
arm64 randconfig-003-20251225 gcc-11.5.0
arm64 randconfig-004-20251225 clang-22
arm64 randconfig-004-20251225 gcc-11.5.0
csky allmodconfig gcc-15.1.0
csky allnoconfig gcc-15.1.0
csky defconfig gcc-15.1.0
csky randconfig-001-20251225 gcc-11.5.0
csky randconfig-001-20251225 gcc-15.1.0
csky randconfig-002-20251225 gcc-11.5.0
hexagon allmodconfig clang-17
hexagon allmodconfig gcc-15.1.0
hexagon allnoconfig clang-22
hexagon allnoconfig gcc-15.1.0
hexagon defconfig gcc-15.1.0
hexagon randconfig-001-20251225 clang-22
hexagon randconfig-002-20251225 clang-22
i386 allmodconfig clang-20
i386 allmodconfig gcc-14
i386 allnoconfig gcc-14
i386 allnoconfig gcc-15.1.0
i386 allyesconfig clang-20
i386 allyesconfig gcc-14
i386 buildonly-randconfig-001-20251225 clang-20
i386 buildonly-randconfig-002-20251225 clang-20
i386 buildonly-randconfig-003-20251225 clang-20
i386 buildonly-randconfig-003-20251225 gcc-14
i386 buildonly-randconfig-004-20251225 clang-20
i386 buildonly-randconfig-005-20251225 clang-20
i386 buildonly-randconfig-006-20251225 clang-20
i386 randconfig-007-20251225 clang-20
i386 randconfig-011-20251225 clang-20
i386 randconfig-011-20251225 gcc-14
i386 randconfig-012-20251225 gcc-14
i386 randconfig-013-20251225 gcc-14
i386 randconfig-014-20251225 clang-20
i386 randconfig-014-20251225 gcc-14
i386 randconfig-015-20251225 gcc-14
i386 randconfig-016-20251225 clang-20
i386 randconfig-016-20251225 gcc-14
i386 randconfig-017-20251225 clang-20
i386 randconfig-017-20251225 gcc-14
loongarch allmodconfig clang-19
loongarch allmodconfig clang-22
loongarch allnoconfig clang-22
loongarch allnoconfig gcc-15.1.0
loongarch defconfig clang-19
loongarch randconfig-001-20251225 clang-22
loongarch randconfig-002-20251225 clang-22
loongarch randconfig-002-20251225 gcc-15.1.0
m68k allmodconfig gcc-15.1.0
m68k allnoconfig gcc-15.1.0
m68k allyesconfig clang-16
m68k allyesconfig gcc-15.1.0
m68k defconfig clang-19
microblaze allnoconfig gcc-15.1.0
microblaze allyesconfig gcc-15.1.0
microblaze defconfig clang-19
mips allmodconfig gcc-15.1.0
mips allnoconfig gcc-15.1.0
mips allyesconfig gcc-15.1.0
mips gcw0_defconfig gcc-15.1.0
nios2 allmodconfig clang-22
nios2 allmodconfig gcc-11.5.0
nios2 allnoconfig clang-22
nios2 allnoconfig gcc-11.5.0
nios2 defconfig clang-19
nios2 randconfig-001-20251225 clang-22
nios2 randconfig-001-20251225 gcc-9.5.0
nios2 randconfig-002-20251225 clang-22
nios2 randconfig-002-20251225 gcc-11.5.0
openrisc allmodconfig clang-22
openrisc allmodconfig gcc-15.1.0
openrisc allnoconfig clang-22
openrisc allnoconfig gcc-15.1.0
openrisc defconfig gcc-15.1.0
parisc allmodconfig gcc-15.1.0
parisc allnoconfig clang-22
parisc allnoconfig gcc-15.1.0
parisc allyesconfig clang-19
parisc allyesconfig gcc-15.1.0
parisc defconfig gcc-15.1.0
parisc randconfig-001-20251225 clang-22
parisc randconfig-002-20251225 clang-22
parisc64 defconfig clang-19
powerpc allmodconfig gcc-15.1.0
powerpc allnoconfig clang-22
powerpc allnoconfig gcc-15.1.0
powerpc cell_defconfig gcc-15.1.0
powerpc pmac32_defconfig gcc-15.1.0
powerpc randconfig-001-20251225 clang-22
powerpc randconfig-002-20251225 clang-22
powerpc64 randconfig-001-20251225 clang-22
powerpc64 randconfig-002-20251225 clang-22
riscv allmodconfig clang-22
riscv allnoconfig clang-22
riscv allnoconfig gcc-15.1.0
riscv allyesconfig clang-16
riscv defconfig clang-22
riscv defconfig gcc-15.1.0
riscv randconfig-001-20251225 clang-19
riscv randconfig-001-20251225 clang-22
riscv randconfig-002-20251225 clang-19
riscv randconfig-002-20251225 gcc-11.5.0
s390 allmodconfig clang-18
s390 allmodconfig clang-19
s390 allnoconfig clang-22
s390 allyesconfig gcc-15.1.0
s390 defconfig clang-22
s390 defconfig gcc-15.1.0
s390 randconfig-001-20251225 clang-19
s390 randconfig-001-20251225 gcc-14.3.0
s390 randconfig-002-20251225 clang-19
sh allmodconfig gcc-15.1.0
sh allnoconfig clang-22
sh allnoconfig gcc-15.1.0
sh allyesconfig clang-19
sh allyesconfig gcc-15.1.0
sh defconfig gcc-14
sh randconfig-001-20251225 clang-19
sh randconfig-001-20251225 gcc-15.1.0
sh randconfig-002-20251225 clang-19
sh randconfig-002-20251225 gcc-9.5.0
sh se7724_defconfig gcc-15.1.0
sparc allnoconfig clang-22
sparc allnoconfig gcc-15.1.0
sparc defconfig gcc-15.1.0
sparc randconfig-001-20251225 gcc-13
sparc randconfig-002-20251225 gcc-13
sparc64 allmodconfig clang-22
sparc64 defconfig gcc-14
sparc64 randconfig-001-20251225 gcc-13
sparc64 randconfig-002-20251225 gcc-13
um allmodconfig clang-19
um allnoconfig clang-22
um allyesconfig gcc-14
um allyesconfig gcc-15.1.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20251225 gcc-13
um randconfig-002-20251225 gcc-13
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-20
x86_64 allnoconfig clang-22
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20251225 clang-20
x86_64 buildonly-randconfig-001-20251225 gcc-14
x86_64 buildonly-randconfig-002-20251225 clang-20
x86_64 buildonly-randconfig-002-20251225 gcc-14
x86_64 buildonly-randconfig-003-20251225 gcc-14
x86_64 buildonly-randconfig-004-20251225 clang-20
x86_64 buildonly-randconfig-004-20251225 gcc-14
x86_64 buildonly-randconfig-005-20251225 gcc-14
x86_64 buildonly-randconfig-006-20251225 clang-20
x86_64 buildonly-randconfig-006-20251225 gcc-14
x86_64 defconfig gcc-14
x86_64 kexec clang-20
x86_64 randconfig-001-20251225 clang-20
x86_64 randconfig-002-20251225 clang-20
x86_64 randconfig-003-20251225 clang-20
x86_64 randconfig-004-20251225 clang-20
x86_64 randconfig-005-20251225 clang-20
x86_64 randconfig-006-20251225 clang-20
x86_64 randconfig-011-20251225 gcc-13
x86_64 randconfig-012-20251225 gcc-13
x86_64 randconfig-012-20251225 gcc-14
x86_64 randconfig-013-20251225 clang-20
x86_64 randconfig-013-20251225 gcc-13
x86_64 randconfig-014-20251225 clang-20
x86_64 randconfig-014-20251225 gcc-13
x86_64 randconfig-015-20251225 gcc-13
x86_64 randconfig-015-20251225 gcc-14
x86_64 randconfig-016-20251225 clang-20
x86_64 randconfig-016-20251225 gcc-13
x86_64 randconfig-071-20251225 clang-20
x86_64 randconfig-072-20251225 clang-20
x86_64 randconfig-073-20251225 clang-20
x86_64 randconfig-073-20251225 gcc-14
x86_64 randconfig-074-20251225 clang-20
x86_64 randconfig-075-20251225 clang-20
x86_64 randconfig-075-20251225 gcc-14
x86_64 randconfig-076-20251225 clang-20
x86_64 randconfig-076-20251225 gcc-14
x86_64 rhel-9.4 clang-20
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-20
x86_64 rhel-9.4-kselftests clang-20
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig clang-22
xtensa allnoconfig gcc-15.1.0
xtensa allyesconfig clang-22
xtensa randconfig-001-20251225 gcc-13
xtensa randconfig-002-20251225 gcc-13
Merry Christmas everybody!
Steven Rostedt (1):
tracing: Remove size parameter in __trace_puts()
Yury Norov (NVIDIA) (6):
kernel.h: drop STACK_MAGIC macro
moduleparam: include required headers explicitly
kernel.h: move VERIFY_OCTAL_PERMISSIONS() to sysfs.h
kernel.h: include linux/instruction_pointer.h explicitly
tracing: move tracing declarations from kernel.h to a dedicated header
kernel.h: drop trace_printk.h
Documentation/filesystems/sysfs.rst | 2 +-
arch/powerpc/kvm/book3s_xics.c | 1 +
arch/powerpc/xmon/xmon.c | 1 +
arch/s390/include/asm/processor.h | 1 +
arch/s390/kernel/ipl.c | 1 +
arch/s390/kernel/machine_kexec.c | 1 +
drivers/gpu/drm/i915/gt/intel_gtt.h | 1 +
.../drm/i915/gt/selftest_ring_submission.c | 1 +
drivers/gpu/drm/i915/i915_gem.h | 1 +
drivers/gpu/drm/i915/i915_selftest.h | 2 +
drivers/hwtracing/stm/dummy_stm.c | 1 +
drivers/infiniband/hw/hfi1/trace_dbg.h | 1 +
drivers/tty/sysrq.c | 1 +
drivers/usb/early/xhci-dbc.c | 1 +
fs/ext4/inline.c | 1 +
include/linux/kernel.h | 209 ------------------
include/linux/moduleparam.h | 7 +-
include/linux/sunrpc/debug.h | 1 +
include/linux/sysfs.h | 13 ++
include/linux/trace_printk.h | 204 +++++++++++++++++
include/linux/ww_mutex.h | 1 +
kernel/debug/debug_core.c | 1 +
kernel/panic.c | 1 +
kernel/rcu/rcu.h | 1 +
kernel/rcu/rcutorture.c | 1 +
kernel/trace/error_report-traces.c | 1 +
kernel/trace/ring_buffer_benchmark.c | 1 +
kernel/trace/trace.c | 8 +-
kernel/trace/trace.h | 2 +-
kernel/trace/trace_benchmark.c | 1 +
kernel/trace/trace_events_trigger.c | 1 +
kernel/trace/trace_functions.c | 1 +
kernel/trace/trace_printk.c | 1 +
kernel/trace/trace_selftest.c | 1 +
lib/sys_info.c | 1 +
samples/fprobe/fprobe_example.c | 1 +
samples/ftrace/ftrace-direct-modify.c | 1 +
samples/ftrace/ftrace-direct-multi-modify.c | 1 +
samples/ftrace/ftrace-direct-multi.c | 1 +
samples/ftrace/ftrace-direct-too.c | 1 +
samples/ftrace/ftrace-direct.c | 1 +
samples/trace_printk/trace-printk.c | 1 +
sound/hda/common/sysfs.c | 1 +
43 files changed, 266 insertions(+), 216 deletions(-)
create mode 100644 include/linux/trace_printk.h
--
2.43.0
^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH v4 1/7] kernel.h: drop STACK_MAGIC macro
2025-12-25 17:09 [PATCH v4 0/7] Unload linux/kernel.h Yury Norov (NVIDIA)
@ 2025-12-25 17:09 ` Yury Norov (NVIDIA)
2025-12-25 17:09 ` [PATCH v4 2/7] moduleparam: include required headers explicitly Yury Norov (NVIDIA)
` (5 subsequent siblings)
6 siblings, 0 replies; 28+ messages in thread
From: Yury Norov (NVIDIA) @ 2025-12-25 17:09 UTC (permalink / raw)
To: Steven Rostedt, Andrew Morton, Masami Hiramatsu,
Mathieu Desnoyers, Andy Shevchenko, Christophe Leroy,
Randy Dunlap, Ingo Molnar, Jani Nikula, Joonas Lahtinen,
David Laight, Petr Pavlu, Andi Shyti, Rodrigo Vivi,
Tvrtko Ursulin, Daniel Gomez, Greg Kroah-Hartman,
Rafael J. Wysocki, Danilo Krummrich, linux-kernel, intel-gfx,
dri-devel, linux-modules, linux-trace-kernel
Cc: Yury Norov (NVIDIA), Jani Nikula, Aaron Tomlin, Andi Shyti
The macro was introduced in 1994, v1.0.4, for stacks protection. Since
that, people found better ways to protect stacks, and now the macro is
only used by i915 selftests. Move it to a local header and drop from
the kernel.h.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
Reviewed-by: Aaron Tomlin <atomlin@atomlin.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
---
drivers/gpu/drm/i915/gt/selftest_ring_submission.c | 1 +
drivers/gpu/drm/i915/i915_selftest.h | 2 ++
include/linux/kernel.h | 2 --
3 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_ring_submission.c b/drivers/gpu/drm/i915/gt/selftest_ring_submission.c
index 87ceb0f374b6..600333ae6c8c 100644
--- a/drivers/gpu/drm/i915/gt/selftest_ring_submission.c
+++ b/drivers/gpu/drm/i915/gt/selftest_ring_submission.c
@@ -3,6 +3,7 @@
* Copyright © 2020 Intel Corporation
*/
+#include "i915_selftest.h"
#include "intel_engine_pm.h"
#include "selftests/igt_flush_test.h"
diff --git a/drivers/gpu/drm/i915/i915_selftest.h b/drivers/gpu/drm/i915/i915_selftest.h
index bdf3e22c0a34..72922028f4ba 100644
--- a/drivers/gpu/drm/i915/i915_selftest.h
+++ b/drivers/gpu/drm/i915/i915_selftest.h
@@ -26,6 +26,8 @@
#include <linux/types.h>
+#define STACK_MAGIC 0xdeadbeef
+
struct pci_dev;
struct drm_i915_private;
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 5b46924fdff5..61d63c57bc2d 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -40,8 +40,6 @@
#include <uapi/linux/kernel.h>
-#define STACK_MAGIC 0xdeadbeef
-
struct completion;
struct user;
--
2.43.0
^ permalink raw reply related [flat|nested] 28+ messages in thread
* [PATCH v4 2/7] moduleparam: include required headers explicitly
2025-12-25 17:09 [PATCH v4 0/7] Unload linux/kernel.h Yury Norov (NVIDIA)
2025-12-25 17:09 ` [PATCH v4 1/7] kernel.h: drop STACK_MAGIC macro Yury Norov (NVIDIA)
@ 2025-12-25 17:09 ` Yury Norov (NVIDIA)
2025-12-25 17:09 ` [PATCH v4 3/7] kernel.h: move VERIFY_OCTAL_PERMISSIONS() to sysfs.h Yury Norov (NVIDIA)
` (4 subsequent siblings)
6 siblings, 0 replies; 28+ messages in thread
From: Yury Norov (NVIDIA) @ 2025-12-25 17:09 UTC (permalink / raw)
To: Steven Rostedt, Andrew Morton, Masami Hiramatsu,
Mathieu Desnoyers, Andy Shevchenko, Christophe Leroy,
Randy Dunlap, Ingo Molnar, Jani Nikula, Joonas Lahtinen,
David Laight, Petr Pavlu, Andi Shyti, Rodrigo Vivi,
Tvrtko Ursulin, Daniel Gomez, Greg Kroah-Hartman,
Rafael J. Wysocki, Danilo Krummrich, linux-kernel, intel-gfx,
dri-devel, linux-modules, linux-trace-kernel
Cc: Yury Norov (NVIDIA)
The following patch drops moduleparam.h dependency on kernel.h. In
preparation to it, list all the required headers explicitly.
Suggested-by: Petr Pavlu <petr.pavlu@suse.com>
Reviewed-by: Petr Pavlu <petr.pavlu@suse.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
---
include/linux/moduleparam.h | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/include/linux/moduleparam.h b/include/linux/moduleparam.h
index 915f32f7d888..03a977168c52 100644
--- a/include/linux/moduleparam.h
+++ b/include/linux/moduleparam.h
@@ -2,9 +2,14 @@
#ifndef _LINUX_MODULE_PARAMS_H
#define _LINUX_MODULE_PARAMS_H
/* (C) Copyright 2001, 2002 Rusty Russell IBM Corporation */
+
+#include <linux/array_size.h>
+#include <linux/build_bug.h>
+#include <linux/compiler.h>
#include <linux/init.h>
#include <linux/stringify.h>
#include <linux/kernel.h>
+#include <linux/types.h>
/*
* The maximum module name length, including the NUL byte.
--
2.43.0
^ permalink raw reply related [flat|nested] 28+ messages in thread
* [PATCH v4 3/7] kernel.h: move VERIFY_OCTAL_PERMISSIONS() to sysfs.h
2025-12-25 17:09 [PATCH v4 0/7] Unload linux/kernel.h Yury Norov (NVIDIA)
2025-12-25 17:09 ` [PATCH v4 1/7] kernel.h: drop STACK_MAGIC macro Yury Norov (NVIDIA)
2025-12-25 17:09 ` [PATCH v4 2/7] moduleparam: include required headers explicitly Yury Norov (NVIDIA)
@ 2025-12-25 17:09 ` Yury Norov (NVIDIA)
2025-12-25 17:09 ` [PATCH v4 4/7] kernel.h: include linux/instruction_pointer.h explicitly Yury Norov (NVIDIA)
` (3 subsequent siblings)
6 siblings, 0 replies; 28+ messages in thread
From: Yury Norov (NVIDIA) @ 2025-12-25 17:09 UTC (permalink / raw)
To: Steven Rostedt, Andrew Morton, Masami Hiramatsu,
Mathieu Desnoyers, Andy Shevchenko, Christophe Leroy,
Randy Dunlap, Ingo Molnar, Jani Nikula, Joonas Lahtinen,
David Laight, Petr Pavlu, Andi Shyti, Rodrigo Vivi,
Tvrtko Ursulin, Daniel Gomez, Greg Kroah-Hartman,
Rafael J. Wysocki, Danilo Krummrich, linux-kernel, intel-gfx,
dri-devel, linux-modules, linux-trace-kernel
Cc: Yury Norov (NVIDIA)
The macro is related to sysfs, but is defined in kernel.h. Move it to
the proper header, and unload the generic kernel.h.
Now that the macro is removed from kernel.h, linux/moduleparam.h is
decoupled, and kernel.h inclusion can be removed.
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Petr Pavlu <petr.pavlu@suse.com>
Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
---
Documentation/filesystems/sysfs.rst | 2 +-
include/linux/kernel.h | 12 ------------
include/linux/moduleparam.h | 2 +-
include/linux/sysfs.h | 13 +++++++++++++
4 files changed, 15 insertions(+), 14 deletions(-)
diff --git a/Documentation/filesystems/sysfs.rst b/Documentation/filesystems/sysfs.rst
index 2703c04af7d0..ffcef4d6bc8d 100644
--- a/Documentation/filesystems/sysfs.rst
+++ b/Documentation/filesystems/sysfs.rst
@@ -120,7 +120,7 @@ is equivalent to doing::
.store = store_foo,
};
-Note as stated in include/linux/kernel.h "OTHER_WRITABLE? Generally
+Note as stated in include/linux/sysfs.h "OTHER_WRITABLE? Generally
considered a bad idea." so trying to set a sysfs file writable for
everyone will fail reverting to RO mode for "Others".
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 61d63c57bc2d..5b879bfea948 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -389,16 +389,4 @@ static inline void ftrace_dump(enum ftrace_dump_mode oops_dump_mode) { }
# define REBUILD_DUE_TO_DYNAMIC_FTRACE
#endif
-/* Permissions on a sysfs file: you didn't miss the 0 prefix did you? */
-#define VERIFY_OCTAL_PERMISSIONS(perms) \
- (BUILD_BUG_ON_ZERO((perms) < 0) + \
- BUILD_BUG_ON_ZERO((perms) > 0777) + \
- /* USER_READABLE >= GROUP_READABLE >= OTHER_READABLE */ \
- BUILD_BUG_ON_ZERO((((perms) >> 6) & 4) < (((perms) >> 3) & 4)) + \
- BUILD_BUG_ON_ZERO((((perms) >> 3) & 4) < ((perms) & 4)) + \
- /* USER_WRITABLE >= GROUP_WRITABLE */ \
- BUILD_BUG_ON_ZERO((((perms) >> 6) & 2) < (((perms) >> 3) & 2)) + \
- /* OTHER_WRITABLE? Generally considered a bad idea. */ \
- BUILD_BUG_ON_ZERO((perms) & 2) + \
- (perms))
#endif
diff --git a/include/linux/moduleparam.h b/include/linux/moduleparam.h
index 03a977168c52..281a006dc284 100644
--- a/include/linux/moduleparam.h
+++ b/include/linux/moduleparam.h
@@ -8,7 +8,7 @@
#include <linux/compiler.h>
#include <linux/init.h>
#include <linux/stringify.h>
-#include <linux/kernel.h>
+#include <linux/sysfs.h>
#include <linux/types.h>
/*
diff --git a/include/linux/sysfs.h b/include/linux/sysfs.h
index c33a96b7391a..99b775f3ff46 100644
--- a/include/linux/sysfs.h
+++ b/include/linux/sysfs.h
@@ -808,4 +808,17 @@ static inline void sysfs_put(struct kernfs_node *kn)
kernfs_put(kn);
}
+/* Permissions on a sysfs file: you didn't miss the 0 prefix did you? */
+#define VERIFY_OCTAL_PERMISSIONS(perms) \
+ (BUILD_BUG_ON_ZERO((perms) < 0) + \
+ BUILD_BUG_ON_ZERO((perms) > 0777) + \
+ /* USER_READABLE >= GROUP_READABLE >= OTHER_READABLE */ \
+ BUILD_BUG_ON_ZERO((((perms) >> 6) & 4) < (((perms) >> 3) & 4)) + \
+ BUILD_BUG_ON_ZERO((((perms) >> 3) & 4) < ((perms) & 4)) + \
+ /* USER_WRITABLE >= GROUP_WRITABLE */ \
+ BUILD_BUG_ON_ZERO((((perms) >> 6) & 2) < (((perms) >> 3) & 2)) + \
+ /* OTHER_WRITABLE? Generally considered a bad idea. */ \
+ BUILD_BUG_ON_ZERO((perms) & 2) + \
+ (perms))
+
#endif /* _SYSFS_H_ */
--
2.43.0
^ permalink raw reply related [flat|nested] 28+ messages in thread
* [PATCH v4 4/7] kernel.h: include linux/instruction_pointer.h explicitly
2025-12-25 17:09 [PATCH v4 0/7] Unload linux/kernel.h Yury Norov (NVIDIA)
` (2 preceding siblings ...)
2025-12-25 17:09 ` [PATCH v4 3/7] kernel.h: move VERIFY_OCTAL_PERMISSIONS() to sysfs.h Yury Norov (NVIDIA)
@ 2025-12-25 17:09 ` Yury Norov (NVIDIA)
2025-12-25 17:09 ` [PATCH v4 5/7] tracing: Remove size parameter in __trace_puts() Yury Norov (NVIDIA)
` (2 subsequent siblings)
6 siblings, 0 replies; 28+ messages in thread
From: Yury Norov (NVIDIA) @ 2025-12-25 17:09 UTC (permalink / raw)
To: Steven Rostedt, Andrew Morton, Masami Hiramatsu,
Mathieu Desnoyers, Andy Shevchenko, Christophe Leroy,
Randy Dunlap, Ingo Molnar, Jani Nikula, Joonas Lahtinen,
David Laight, Petr Pavlu, Andi Shyti, Rodrigo Vivi,
Tvrtko Ursulin, Daniel Gomez, Greg Kroah-Hartman,
Rafael J. Wysocki, Danilo Krummrich, linux-kernel, intel-gfx,
dri-devel, linux-modules, linux-trace-kernel
Cc: Yury Norov (NVIDIA)
In preparation for decoupling linux/instruction_pointer.h and
linux/kernel.h, include instruction_pointer.h explicitly where needed.
Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
---
arch/s390/include/asm/processor.h | 1 +
include/linux/ww_mutex.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/arch/s390/include/asm/processor.h b/arch/s390/include/asm/processor.h
index 3affba95845b..cc187afa07b3 100644
--- a/arch/s390/include/asm/processor.h
+++ b/arch/s390/include/asm/processor.h
@@ -31,6 +31,7 @@
#include <linux/cpumask.h>
#include <linux/linkage.h>
#include <linux/irqflags.h>
+#include <linux/instruction_pointer.h>
#include <linux/bitops.h>
#include <asm/fpu-types.h>
#include <asm/cpu.h>
diff --git a/include/linux/ww_mutex.h b/include/linux/ww_mutex.h
index 45ff6f7a872b..9b30fa2ec508 100644
--- a/include/linux/ww_mutex.h
+++ b/include/linux/ww_mutex.h
@@ -17,6 +17,7 @@
#ifndef __LINUX_WW_MUTEX_H
#define __LINUX_WW_MUTEX_H
+#include <linux/instruction_pointer.h>
#include <linux/mutex.h>
#include <linux/rtmutex.h>
--
2.43.0
^ permalink raw reply related [flat|nested] 28+ messages in thread
* [PATCH v4 5/7] tracing: Remove size parameter in __trace_puts()
2025-12-25 17:09 [PATCH v4 0/7] Unload linux/kernel.h Yury Norov (NVIDIA)
` (3 preceding siblings ...)
2025-12-25 17:09 ` [PATCH v4 4/7] kernel.h: include linux/instruction_pointer.h explicitly Yury Norov (NVIDIA)
@ 2025-12-25 17:09 ` Yury Norov (NVIDIA)
2025-12-25 17:09 ` [PATCH v4 6/7] tracing: move tracing declarations from kernel.h to a dedicated header Yury Norov (NVIDIA)
2025-12-25 17:09 ` [PATCH v4 7/7] kernel.h: drop trace_printk.h Yury Norov (NVIDIA)
6 siblings, 0 replies; 28+ messages in thread
From: Yury Norov (NVIDIA) @ 2025-12-25 17:09 UTC (permalink / raw)
To: Steven Rostedt, Andrew Morton, Masami Hiramatsu,
Mathieu Desnoyers, Andy Shevchenko, Christophe Leroy,
Randy Dunlap, Ingo Molnar, Jani Nikula, Joonas Lahtinen,
David Laight, Petr Pavlu, Andi Shyti, Rodrigo Vivi,
Tvrtko Ursulin, Daniel Gomez, Greg Kroah-Hartman,
Rafael J. Wysocki, Danilo Krummrich, linux-kernel, intel-gfx,
dri-devel, linux-modules, linux-trace-kernel
Cc: Yury Norov (NVIDIA)
From: Steven Rostedt <rostedt@goodmis.org>
The __trace_puts() function takes a string pointer and the size of the
string itself. All users currently simply pass in the strlen() of the
string it is also passing in. There's no reason to pass in the size.
Instead have the __trace_puts() function do the strlen() within the
function itself.
This fixes a header recursion issue where using strlen() in the macro
calling __trace_puts() requires adding #include <linux/string.h> in order
to use strlen(). Removing the use of strlen() from the header fixes the
recursion issue.
Link: https://lore.kernel.org/all/aUN8Hm377C5A0ILX@yury/
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
---
include/linux/kernel.h | 4 ++--
kernel/trace/trace.c | 7 +++----
kernel/trace/trace.h | 2 +-
3 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 5b879bfea948..4ee48fb10dec 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -329,10 +329,10 @@ int __trace_printk(unsigned long ip, const char *fmt, ...);
if (__builtin_constant_p(str)) \
__trace_bputs(_THIS_IP_, trace_printk_fmt); \
else \
- __trace_puts(_THIS_IP_, str, strlen(str)); \
+ __trace_puts(_THIS_IP_, str); \
})
extern int __trace_bputs(unsigned long ip, const char *str);
-extern int __trace_puts(unsigned long ip, const char *str, int size);
+extern int __trace_puts(unsigned long ip, const char *str);
extern void trace_dump_stack(int skip);
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 6f2148df14d9..57f24e2cd19c 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -1178,11 +1178,10 @@ EXPORT_SYMBOL_GPL(__trace_array_puts);
* __trace_puts - write a constant string into the trace buffer.
* @ip: The address of the caller
* @str: The constant string to write
- * @size: The size of the string.
*/
-int __trace_puts(unsigned long ip, const char *str, int size)
+int __trace_puts(unsigned long ip, const char *str)
{
- return __trace_array_puts(printk_trace, ip, str, size);
+ return __trace_array_puts(printk_trace, ip, str, strlen(str));
}
EXPORT_SYMBOL_GPL(__trace_puts);
@@ -1201,7 +1200,7 @@ int __trace_bputs(unsigned long ip, const char *str)
int size = sizeof(struct bputs_entry);
if (!printk_binsafe(tr))
- return __trace_puts(ip, str, strlen(str));
+ return __trace_puts(ip, str);
if (!(tr->trace_flags & TRACE_ITER(PRINTK)))
return 0;
diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index b6d42fe06115..de4e6713b84e 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -2116,7 +2116,7 @@ extern void tracing_log_err(struct trace_array *tr,
* about performance). The internal_trace_puts() is for such
* a purpose.
*/
-#define internal_trace_puts(str) __trace_puts(_THIS_IP_, str, strlen(str))
+#define internal_trace_puts(str) __trace_puts(_THIS_IP_, str)
#undef FTRACE_ENTRY
#define FTRACE_ENTRY(call, struct_name, id, tstruct, print) \
--
2.43.0
^ permalink raw reply related [flat|nested] 28+ messages in thread
* [PATCH v4 6/7] tracing: move tracing declarations from kernel.h to a dedicated header
2025-12-25 17:09 [PATCH v4 0/7] Unload linux/kernel.h Yury Norov (NVIDIA)
` (4 preceding siblings ...)
2025-12-25 17:09 ` [PATCH v4 5/7] tracing: Remove size parameter in __trace_puts() Yury Norov (NVIDIA)
@ 2025-12-25 17:09 ` Yury Norov (NVIDIA)
2025-12-25 17:09 ` [PATCH v4 7/7] kernel.h: drop trace_printk.h Yury Norov (NVIDIA)
6 siblings, 0 replies; 28+ messages in thread
From: Yury Norov (NVIDIA) @ 2025-12-25 17:09 UTC (permalink / raw)
To: Steven Rostedt, Andrew Morton, Masami Hiramatsu,
Mathieu Desnoyers, Andy Shevchenko, Christophe Leroy,
Randy Dunlap, Ingo Molnar, Jani Nikula, Joonas Lahtinen,
David Laight, Petr Pavlu, Andi Shyti, Rodrigo Vivi,
Tvrtko Ursulin, Daniel Gomez, Greg Kroah-Hartman,
Rafael J. Wysocki, Danilo Krummrich, linux-kernel, intel-gfx,
dri-devel, linux-modules, linux-trace-kernel
Cc: Yury Norov (NVIDIA)
Tracing is a half of the kernel.h in terms of LOCs, although it's
a self-consistent part. It is intended for quick debugging purposes
and isn't used by the normal tracing utilities.
Move it to a separate header. If someone needs to just throw a
trace_printk() in their driver, they will not have to pull all
the heavy tracing machinery.
This is a pure move.
Acked-by: Steven Rostedt <rostedt@goodmis.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
---
include/linux/kernel.h | 196 +--------------------------------
include/linux/trace_printk.h | 204 +++++++++++++++++++++++++++++++++++
2 files changed, 205 insertions(+), 195 deletions(-)
create mode 100644 include/linux/trace_printk.h
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 4ee48fb10dec..a377335e01da 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -32,7 +32,7 @@
#include <linux/build_bug.h>
#include <linux/sprintf.h>
#include <linux/static_call_types.h>
-#include <linux/instruction_pointer.h>
+#include <linux/trace_printk.h>
#include <linux/util_macros.h>
#include <linux/wordpart.h>
@@ -190,200 +190,6 @@ enum system_states {
};
extern enum system_states system_state;
-/*
- * General tracing related utility functions - trace_printk(),
- * tracing_on/tracing_off and tracing_start()/tracing_stop
- *
- * Use tracing_on/tracing_off when you want to quickly turn on or off
- * tracing. It simply enables or disables the recording of the trace events.
- * This also corresponds to the user space /sys/kernel/tracing/tracing_on
- * file, which gives a means for the kernel and userspace to interact.
- * Place a tracing_off() in the kernel where you want tracing to end.
- * From user space, examine the trace, and then echo 1 > tracing_on
- * to continue tracing.
- *
- * tracing_stop/tracing_start has slightly more overhead. It is used
- * by things like suspend to ram where disabling the recording of the
- * trace is not enough, but tracing must actually stop because things
- * like calling smp_processor_id() may crash the system.
- *
- * Most likely, you want to use tracing_on/tracing_off.
- */
-
-enum ftrace_dump_mode {
- DUMP_NONE,
- DUMP_ALL,
- DUMP_ORIG,
- DUMP_PARAM,
-};
-
-#ifdef CONFIG_TRACING
-void tracing_on(void);
-void tracing_off(void);
-int tracing_is_on(void);
-void tracing_snapshot(void);
-void tracing_snapshot_alloc(void);
-
-extern void tracing_start(void);
-extern void tracing_stop(void);
-
-static inline __printf(1, 2)
-void ____trace_printk_check_format(const char *fmt, ...)
-{
-}
-#define __trace_printk_check_format(fmt, args...) \
-do { \
- if (0) \
- ____trace_printk_check_format(fmt, ##args); \
-} while (0)
-
-/**
- * trace_printk - printf formatting in the ftrace buffer
- * @fmt: the printf format for printing
- *
- * Note: __trace_printk is an internal function for trace_printk() and
- * the @ip is passed in via the trace_printk() macro.
- *
- * This function allows a kernel developer to debug fast path sections
- * that printk is not appropriate for. By scattering in various
- * printk like tracing in the code, a developer can quickly see
- * where problems are occurring.
- *
- * This is intended as a debugging tool for the developer only.
- * Please refrain from leaving trace_printks scattered around in
- * your code. (Extra memory is used for special buffers that are
- * allocated when trace_printk() is used.)
- *
- * A little optimization trick is done here. If there's only one
- * argument, there's no need to scan the string for printf formats.
- * The trace_puts() will suffice. But how can we take advantage of
- * using trace_puts() when trace_printk() has only one argument?
- * By stringifying the args and checking the size we can tell
- * whether or not there are args. __stringify((__VA_ARGS__)) will
- * turn into "()\0" with a size of 3 when there are no args, anything
- * else will be bigger. All we need to do is define a string to this,
- * and then take its size and compare to 3. If it's bigger, use
- * do_trace_printk() otherwise, optimize it to trace_puts(). Then just
- * let gcc optimize the rest.
- */
-
-#define trace_printk(fmt, ...) \
-do { \
- char _______STR[] = __stringify((__VA_ARGS__)); \
- if (sizeof(_______STR) > 3) \
- do_trace_printk(fmt, ##__VA_ARGS__); \
- else \
- trace_puts(fmt); \
-} while (0)
-
-#define do_trace_printk(fmt, args...) \
-do { \
- static const char *trace_printk_fmt __used \
- __section("__trace_printk_fmt") = \
- __builtin_constant_p(fmt) ? fmt : NULL; \
- \
- __trace_printk_check_format(fmt, ##args); \
- \
- if (__builtin_constant_p(fmt)) \
- __trace_bprintk(_THIS_IP_, trace_printk_fmt, ##args); \
- else \
- __trace_printk(_THIS_IP_, fmt, ##args); \
-} while (0)
-
-extern __printf(2, 3)
-int __trace_bprintk(unsigned long ip, const char *fmt, ...);
-
-extern __printf(2, 3)
-int __trace_printk(unsigned long ip, const char *fmt, ...);
-
-/**
- * trace_puts - write a string into the ftrace buffer
- * @str: the string to record
- *
- * Note: __trace_bputs is an internal function for trace_puts and
- * the @ip is passed in via the trace_puts macro.
- *
- * This is similar to trace_printk() but is made for those really fast
- * paths that a developer wants the least amount of "Heisenbug" effects,
- * where the processing of the print format is still too much.
- *
- * This function allows a kernel developer to debug fast path sections
- * that printk is not appropriate for. By scattering in various
- * printk like tracing in the code, a developer can quickly see
- * where problems are occurring.
- *
- * This is intended as a debugging tool for the developer only.
- * Please refrain from leaving trace_puts scattered around in
- * your code. (Extra memory is used for special buffers that are
- * allocated when trace_puts() is used.)
- *
- * Returns: 0 if nothing was written, positive # if string was.
- * (1 when __trace_bputs is used, strlen(str) when __trace_puts is used)
- */
-
-#define trace_puts(str) ({ \
- static const char *trace_printk_fmt __used \
- __section("__trace_printk_fmt") = \
- __builtin_constant_p(str) ? str : NULL; \
- \
- if (__builtin_constant_p(str)) \
- __trace_bputs(_THIS_IP_, trace_printk_fmt); \
- else \
- __trace_puts(_THIS_IP_, str); \
-})
-extern int __trace_bputs(unsigned long ip, const char *str);
-extern int __trace_puts(unsigned long ip, const char *str);
-
-extern void trace_dump_stack(int skip);
-
-/*
- * The double __builtin_constant_p is because gcc will give us an error
- * if we try to allocate the static variable to fmt if it is not a
- * constant. Even with the outer if statement.
- */
-#define ftrace_vprintk(fmt, vargs) \
-do { \
- if (__builtin_constant_p(fmt)) { \
- static const char *trace_printk_fmt __used \
- __section("__trace_printk_fmt") = \
- __builtin_constant_p(fmt) ? fmt : NULL; \
- \
- __ftrace_vbprintk(_THIS_IP_, trace_printk_fmt, vargs); \
- } else \
- __ftrace_vprintk(_THIS_IP_, fmt, vargs); \
-} while (0)
-
-extern __printf(2, 0) int
-__ftrace_vbprintk(unsigned long ip, const char *fmt, va_list ap);
-
-extern __printf(2, 0) int
-__ftrace_vprintk(unsigned long ip, const char *fmt, va_list ap);
-
-extern void ftrace_dump(enum ftrace_dump_mode oops_dump_mode);
-#else
-static inline void tracing_start(void) { }
-static inline void tracing_stop(void) { }
-static inline void trace_dump_stack(int skip) { }
-
-static inline void tracing_on(void) { }
-static inline void tracing_off(void) { }
-static inline int tracing_is_on(void) { return 0; }
-static inline void tracing_snapshot(void) { }
-static inline void tracing_snapshot_alloc(void) { }
-
-static inline __printf(1, 2)
-int trace_printk(const char *fmt, ...)
-{
- return 0;
-}
-static __printf(1, 0) inline int
-ftrace_vprintk(const char *fmt, va_list ap)
-{
- return 0;
-}
-static inline void ftrace_dump(enum ftrace_dump_mode oops_dump_mode) { }
-#endif /* CONFIG_TRACING */
-
/* Rebuild everything on CONFIG_DYNAMIC_FTRACE */
#ifdef CONFIG_DYNAMIC_FTRACE
# define REBUILD_DUE_TO_DYNAMIC_FTRACE
diff --git a/include/linux/trace_printk.h b/include/linux/trace_printk.h
new file mode 100644
index 000000000000..bb5874097f24
--- /dev/null
+++ b/include/linux/trace_printk.h
@@ -0,0 +1,204 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _LINUX_TRACE_PRINTK_H
+#define _LINUX_TRACE_PRINTK_H
+
+#include <linux/compiler_attributes.h>
+#include <linux/instruction_pointer.h>
+#include <linux/stddef.h>
+#include <linux/stringify.h>
+
+/*
+ * General tracing related utility functions - trace_printk(),
+ * tracing_on/tracing_off and tracing_start()/tracing_stop
+ *
+ * Use tracing_on/tracing_off when you want to quickly turn on or off
+ * tracing. It simply enables or disables the recording of the trace events.
+ * This also corresponds to the user space /sys/kernel/tracing/tracing_on
+ * file, which gives a means for the kernel and userspace to interact.
+ * Place a tracing_off() in the kernel where you want tracing to end.
+ * From user space, examine the trace, and then echo 1 > tracing_on
+ * to continue tracing.
+ *
+ * tracing_stop/tracing_start has slightly more overhead. It is used
+ * by things like suspend to ram where disabling the recording of the
+ * trace is not enough, but tracing must actually stop because things
+ * like calling smp_processor_id() may crash the system.
+ *
+ * Most likely, you want to use tracing_on/tracing_off.
+ */
+
+enum ftrace_dump_mode {
+ DUMP_NONE,
+ DUMP_ALL,
+ DUMP_ORIG,
+ DUMP_PARAM,
+};
+
+#ifdef CONFIG_TRACING
+void tracing_on(void);
+void tracing_off(void);
+int tracing_is_on(void);
+void tracing_snapshot(void);
+void tracing_snapshot_alloc(void);
+
+extern void tracing_start(void);
+extern void tracing_stop(void);
+
+static inline __printf(1, 2)
+void ____trace_printk_check_format(const char *fmt, ...)
+{
+}
+#define __trace_printk_check_format(fmt, args...) \
+do { \
+ if (0) \
+ ____trace_printk_check_format(fmt, ##args); \
+} while (0)
+
+/**
+ * trace_printk - printf formatting in the ftrace buffer
+ * @fmt: the printf format for printing
+ *
+ * Note: __trace_printk is an internal function for trace_printk() and
+ * the @ip is passed in via the trace_printk() macro.
+ *
+ * This function allows a kernel developer to debug fast path sections
+ * that printk is not appropriate for. By scattering in various
+ * printk like tracing in the code, a developer can quickly see
+ * where problems are occurring.
+ *
+ * This is intended as a debugging tool for the developer only.
+ * Please refrain from leaving trace_printks scattered around in
+ * your code. (Extra memory is used for special buffers that are
+ * allocated when trace_printk() is used.)
+ *
+ * A little optimization trick is done here. If there's only one
+ * argument, there's no need to scan the string for printf formats.
+ * The trace_puts() will suffice. But how can we take advantage of
+ * using trace_puts() when trace_printk() has only one argument?
+ * By stringifying the args and checking the size we can tell
+ * whether or not there are args. __stringify((__VA_ARGS__)) will
+ * turn into "()\0" with a size of 3 when there are no args, anything
+ * else will be bigger. All we need to do is define a string to this,
+ * and then take its size and compare to 3. If it's bigger, use
+ * do_trace_printk() otherwise, optimize it to trace_puts(). Then just
+ * let gcc optimize the rest.
+ */
+
+#define trace_printk(fmt, ...) \
+do { \
+ char _______STR[] = __stringify((__VA_ARGS__)); \
+ if (sizeof(_______STR) > 3) \
+ do_trace_printk(fmt, ##__VA_ARGS__); \
+ else \
+ trace_puts(fmt); \
+} while (0)
+
+#define do_trace_printk(fmt, args...) \
+do { \
+ static const char *trace_printk_fmt __used \
+ __section("__trace_printk_fmt") = \
+ __builtin_constant_p(fmt) ? fmt : NULL; \
+ \
+ __trace_printk_check_format(fmt, ##args); \
+ \
+ if (__builtin_constant_p(fmt)) \
+ __trace_bprintk(_THIS_IP_, trace_printk_fmt, ##args); \
+ else \
+ __trace_printk(_THIS_IP_, fmt, ##args); \
+} while (0)
+
+extern __printf(2, 3)
+int __trace_bprintk(unsigned long ip, const char *fmt, ...);
+
+extern __printf(2, 3)
+int __trace_printk(unsigned long ip, const char *fmt, ...);
+
+/**
+ * trace_puts - write a string into the ftrace buffer
+ * @str: the string to record
+ *
+ * Note: __trace_bputs is an internal function for trace_puts and
+ * the @ip is passed in via the trace_puts macro.
+ *
+ * This is similar to trace_printk() but is made for those really fast
+ * paths that a developer wants the least amount of "Heisenbug" effects,
+ * where the processing of the print format is still too much.
+ *
+ * This function allows a kernel developer to debug fast path sections
+ * that printk is not appropriate for. By scattering in various
+ * printk like tracing in the code, a developer can quickly see
+ * where problems are occurring.
+ *
+ * This is intended as a debugging tool for the developer only.
+ * Please refrain from leaving trace_puts scattered around in
+ * your code. (Extra memory is used for special buffers that are
+ * allocated when trace_puts() is used.)
+ *
+ * Returns: 0 if nothing was written, positive # if string was.
+ * (1 when __trace_bputs is used, strlen(str) when __trace_puts is used)
+ */
+
+#define trace_puts(str) ({ \
+ static const char *trace_printk_fmt __used \
+ __section("__trace_printk_fmt") = \
+ __builtin_constant_p(str) ? str : NULL; \
+ \
+ if (__builtin_constant_p(str)) \
+ __trace_bputs(_THIS_IP_, trace_printk_fmt); \
+ else \
+ __trace_puts(_THIS_IP_, str); \
+})
+extern int __trace_bputs(unsigned long ip, const char *str);
+extern int __trace_puts(unsigned long ip, const char *str);
+
+extern void trace_dump_stack(int skip);
+
+/*
+ * The double __builtin_constant_p is because gcc will give us an error
+ * if we try to allocate the static variable to fmt if it is not a
+ * constant. Even with the outer if statement.
+ */
+#define ftrace_vprintk(fmt, vargs) \
+do { \
+ if (__builtin_constant_p(fmt)) { \
+ static const char *trace_printk_fmt __used \
+ __section("__trace_printk_fmt") = \
+ __builtin_constant_p(fmt) ? fmt : NULL; \
+ \
+ __ftrace_vbprintk(_THIS_IP_, trace_printk_fmt, vargs); \
+ } else \
+ __ftrace_vprintk(_THIS_IP_, fmt, vargs); \
+} while (0)
+
+extern __printf(2, 0) int
+__ftrace_vbprintk(unsigned long ip, const char *fmt, va_list ap);
+
+extern __printf(2, 0) int
+__ftrace_vprintk(unsigned long ip, const char *fmt, va_list ap);
+
+extern void ftrace_dump(enum ftrace_dump_mode oops_dump_mode);
+#else
+static inline void tracing_start(void) { }
+static inline void tracing_stop(void) { }
+static inline void trace_dump_stack(int skip) { }
+
+static inline void tracing_on(void) { }
+static inline void tracing_off(void) { }
+static inline int tracing_is_on(void) { return 0; }
+static inline void tracing_snapshot(void) { }
+static inline void tracing_snapshot_alloc(void) { }
+
+static inline __printf(1, 2)
+int trace_printk(const char *fmt, ...)
+{
+ return 0;
+}
+static __printf(1, 0) inline int
+ftrace_vprintk(const char *fmt, va_list ap)
+{
+ return 0;
+}
+static inline void ftrace_dump(enum ftrace_dump_mode oops_dump_mode) { }
+#endif /* CONFIG_TRACING */
+
+#endif
--
2.43.0
^ permalink raw reply related [flat|nested] 28+ messages in thread
* [PATCH v4 7/7] kernel.h: drop trace_printk.h
2025-12-25 17:09 [PATCH v4 0/7] Unload linux/kernel.h Yury Norov (NVIDIA)
` (5 preceding siblings ...)
2025-12-25 17:09 ` [PATCH v4 6/7] tracing: move tracing declarations from kernel.h to a dedicated header Yury Norov (NVIDIA)
@ 2025-12-25 17:09 ` Yury Norov (NVIDIA)
2025-12-26 16:58 ` Steven Rostedt
2025-12-27 14:50 ` Andy Shevchenko
6 siblings, 2 replies; 28+ messages in thread
From: Yury Norov (NVIDIA) @ 2025-12-25 17:09 UTC (permalink / raw)
To: Steven Rostedt, Andrew Morton, Masami Hiramatsu,
Mathieu Desnoyers, Andy Shevchenko, Christophe Leroy,
Randy Dunlap, Ingo Molnar, Jani Nikula, Joonas Lahtinen,
David Laight, Petr Pavlu, Andi Shyti, Rodrigo Vivi,
Tvrtko Ursulin, Daniel Gomez, Greg Kroah-Hartman,
Rafael J. Wysocki, Danilo Krummrich, linux-kernel, intel-gfx,
dri-devel, linux-modules, linux-trace-kernel
Cc: Yury Norov (NVIDIA)
The trace_printk.h header is debugging-only by nature, but now it's
included by almost every compilation unit via kernel.h.
Removing trace_printk.h saves 1.5-2% of compilation time on my
Ubuntu-derived x86_64/localyesconfig.
There's ~30 files in the codebase, requiring trace_printk.h for
non-debugging reasons: mostly to disable tracing on panic or under
similar conditions. Include the header for those explicitly.
This implicitly decouples linux/kernel.h and linux/instruction_pointer.h
as well, because it has been isolated to trace_printk.h early in the
series.
Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
---
arch/powerpc/kvm/book3s_xics.c | 1 +
arch/powerpc/xmon/xmon.c | 1 +
arch/s390/kernel/ipl.c | 1 +
arch/s390/kernel/machine_kexec.c | 1 +
drivers/gpu/drm/i915/gt/intel_gtt.h | 1 +
drivers/gpu/drm/i915/i915_gem.h | 1 +
drivers/hwtracing/stm/dummy_stm.c | 1 +
drivers/infiniband/hw/hfi1/trace_dbg.h | 1 +
drivers/tty/sysrq.c | 1 +
drivers/usb/early/xhci-dbc.c | 1 +
fs/ext4/inline.c | 1 +
include/linux/kernel.h | 1 -
include/linux/sunrpc/debug.h | 1 +
kernel/debug/debug_core.c | 1 +
kernel/panic.c | 1 +
kernel/rcu/rcu.h | 1 +
kernel/rcu/rcutorture.c | 1 +
kernel/trace/error_report-traces.c | 1 +
kernel/trace/ring_buffer_benchmark.c | 1 +
kernel/trace/trace.c | 1 +
kernel/trace/trace_benchmark.c | 1 +
kernel/trace/trace_events_trigger.c | 1 +
kernel/trace/trace_functions.c | 1 +
kernel/trace/trace_printk.c | 1 +
kernel/trace/trace_selftest.c | 1 +
lib/sys_info.c | 1 +
samples/fprobe/fprobe_example.c | 1 +
samples/ftrace/ftrace-direct-modify.c | 1 +
samples/ftrace/ftrace-direct-multi-modify.c | 1 +
samples/ftrace/ftrace-direct-multi.c | 1 +
samples/ftrace/ftrace-direct-too.c | 1 +
samples/ftrace/ftrace-direct.c | 1 +
samples/trace_printk/trace-printk.c | 1 +
sound/hda/common/sysfs.c | 1 +
34 files changed, 33 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kvm/book3s_xics.c b/arch/powerpc/kvm/book3s_xics.c
index 589a8f257120..8f8cfc8648c6 100644
--- a/arch/powerpc/kvm/book3s_xics.c
+++ b/arch/powerpc/kvm/book3s_xics.c
@@ -20,6 +20,7 @@
#include <asm/time.h>
#include <linux/seq_file.h>
+#include <linux/trace_printk.h>
#include "book3s_xics.h"
diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index cb3a3244ae6f..f5cf6d807aeb 100644
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerpc/xmon/xmon.c
@@ -27,6 +27,7 @@
#include <linux/highmem.h>
#include <linux/security.h>
#include <linux/debugfs.h>
+#include <linux/trace_printk.h>
#include <asm/ptrace.h>
#include <asm/smp.h>
diff --git a/arch/s390/kernel/ipl.c b/arch/s390/kernel/ipl.c
index dcdc7e274848..55ac9c9eeb36 100644
--- a/arch/s390/kernel/ipl.c
+++ b/arch/s390/kernel/ipl.c
@@ -20,6 +20,7 @@
#include <linux/gfp.h>
#include <linux/crash_dump.h>
#include <linux/debug_locks.h>
+#include <linux/trace_printk.h>
#include <linux/vmalloc.h>
#include <asm/asm-extable.h>
#include <asm/machine.h>
diff --git a/arch/s390/kernel/machine_kexec.c b/arch/s390/kernel/machine_kexec.c
index baeb3dcfc1c8..668d8444b02b 100644
--- a/arch/s390/kernel/machine_kexec.c
+++ b/arch/s390/kernel/machine_kexec.c
@@ -14,6 +14,7 @@
#include <linux/ftrace.h>
#include <linux/debug_locks.h>
#include <linux/cpufeature.h>
+#include <linux/trace_printk.h>
#include <asm/guarded_storage.h>
#include <asm/machine.h>
#include <asm/pfault.h>
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h b/drivers/gpu/drm/i915/gt/intel_gtt.h
index 9d3a3ad567a0..3f6d78a7ccea 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
@@ -22,6 +22,7 @@
#include <linux/pagevec.h>
#include <linux/scatterlist.h>
#include <linux/workqueue.h>
+#include <linux/trace_printk.h>
#include <drm/drm_mm.h>
diff --git a/drivers/gpu/drm/i915/i915_gem.h b/drivers/gpu/drm/i915/i915_gem.h
index 20b3cb29cfff..549fdeaf4508 100644
--- a/drivers/gpu/drm/i915/i915_gem.h
+++ b/drivers/gpu/drm/i915/i915_gem.h
@@ -27,6 +27,7 @@
#include <linux/bug.h>
#include <linux/types.h>
+#include <linux/trace_printk.h>
#include <drm/drm_drv.h>
diff --git a/drivers/hwtracing/stm/dummy_stm.c b/drivers/hwtracing/stm/dummy_stm.c
index 38528ffdc0b3..8464401756f3 100644
--- a/drivers/hwtracing/stm/dummy_stm.c
+++ b/drivers/hwtracing/stm/dummy_stm.c
@@ -12,6 +12,7 @@
#include <linux/module.h>
#include <linux/slab.h>
#include <linux/stm.h>
+#include <linux/trace_printk.h>
#include <uapi/linux/stm.h>
static ssize_t notrace
diff --git a/drivers/infiniband/hw/hfi1/trace_dbg.h b/drivers/infiniband/hw/hfi1/trace_dbg.h
index 58304b91380f..d7c08190d816 100644
--- a/drivers/infiniband/hw/hfi1/trace_dbg.h
+++ b/drivers/infiniband/hw/hfi1/trace_dbg.h
@@ -8,6 +8,7 @@
#include <linux/tracepoint.h>
#include <linux/trace_seq.h>
+#include <linux/trace_printk.h>
#include "hfi.h"
diff --git a/drivers/tty/sysrq.c b/drivers/tty/sysrq.c
index 1f78b0db3b25..72b2555c2bb8 100644
--- a/drivers/tty/sysrq.c
+++ b/drivers/tty/sysrq.c
@@ -51,6 +51,7 @@
#include <linux/syscalls.h>
#include <linux/of.h>
#include <linux/rcupdate.h>
+#include <linux/trace_printk.h>
#include <asm/ptrace.h>
#include <asm/irq_regs.h>
diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c
index 41118bba9197..dce1e2a3e180 100644
--- a/drivers/usb/early/xhci-dbc.c
+++ b/drivers/usb/early/xhci-dbc.c
@@ -22,6 +22,7 @@
#include <linux/delay.h>
#include <linux/kthread.h>
#include <linux/usb/xhci-dbgp.h>
+#include <linux/trace_printk.h>
#include "../host/xhci.h"
#include "xhci-dbc.h"
diff --git a/fs/ext4/inline.c b/fs/ext4/inline.c
index 1f6bc05593df..d15faa78eb07 100644
--- a/fs/ext4/inline.c
+++ b/fs/ext4/inline.c
@@ -9,6 +9,7 @@
#include <linux/namei.h>
#include <linux/iversion.h>
#include <linux/sched/mm.h>
+#include <linux/trace_printk.h>
#include "ext4_jbd2.h"
#include "ext4.h"
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index a377335e01da..c48f7109bb2a 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -32,7 +32,6 @@
#include <linux/build_bug.h>
#include <linux/sprintf.h>
#include <linux/static_call_types.h>
-#include <linux/trace_printk.h>
#include <linux/util_macros.h>
#include <linux/wordpart.h>
diff --git a/include/linux/sunrpc/debug.h b/include/linux/sunrpc/debug.h
index 891f6173c951..db2b572505f5 100644
--- a/include/linux/sunrpc/debug.h
+++ b/include/linux/sunrpc/debug.h
@@ -9,6 +9,7 @@
#ifndef _LINUX_SUNRPC_DEBUG_H_
#define _LINUX_SUNRPC_DEBUG_H_
+#include <linux/trace_printk.h>
#include <uapi/linux/sunrpc/debug.h>
/*
diff --git a/kernel/debug/debug_core.c b/kernel/debug/debug_core.c
index 0b9495187fba..e9209afc78aa 100644
--- a/kernel/debug/debug_core.c
+++ b/kernel/debug/debug_core.c
@@ -53,6 +53,7 @@
#include <linux/rcupdate.h>
#include <linux/irq.h>
#include <linux/security.h>
+#include <linux/trace_printk.h>
#include <asm/cacheflush.h>
#include <asm/byteorder.h>
diff --git a/kernel/panic.c b/kernel/panic.c
index 0d52210a9e2b..b9e1ff90c637 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -37,6 +37,7 @@
#include <linux/context_tracking.h>
#include <linux/seq_buf.h>
#include <linux/sys_info.h>
+#include <linux/trace_printk.h>
#include <trace/events/error_report.h>
#include <asm/sections.h>
diff --git a/kernel/rcu/rcu.h b/kernel/rcu/rcu.h
index 9cf01832a6c3..1c8f5765ba8b 100644
--- a/kernel/rcu/rcu.h
+++ b/kernel/rcu/rcu.h
@@ -12,6 +12,7 @@
#include <linux/slab.h>
#include <trace/events/rcu.h>
+#include <linux/trace_printk.h>
/*
* Grace-period counter management.
diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c
index 07e51974b06b..c2f859c20ca7 100644
--- a/kernel/rcu/rcutorture.c
+++ b/kernel/rcu/rcutorture.c
@@ -48,6 +48,7 @@
#include <linux/tick.h>
#include <linux/rcupdate_trace.h>
#include <linux/nmi.h>
+#include <linux/trace_printk.h>
#include "rcu.h"
diff --git a/kernel/trace/error_report-traces.c b/kernel/trace/error_report-traces.c
index f89792c25b11..6a3c59f39ea2 100644
--- a/kernel/trace/error_report-traces.c
+++ b/kernel/trace/error_report-traces.c
@@ -7,5 +7,6 @@
#define CREATE_TRACE_POINTS
#include <trace/events/error_report.h>
+#include <linux/trace_printk.h>
EXPORT_TRACEPOINT_SYMBOL_GPL(error_report_end);
diff --git a/kernel/trace/ring_buffer_benchmark.c b/kernel/trace/ring_buffer_benchmark.c
index 593e3b59e42e..b977ee0879c1 100644
--- a/kernel/trace/ring_buffer_benchmark.c
+++ b/kernel/trace/ring_buffer_benchmark.c
@@ -10,6 +10,7 @@
#include <uapi/linux/sched/types.h>
#include <linux/module.h>
#include <linux/ktime.h>
+#include <linux/trace_printk.h>
#include <asm/local.h>
struct rb_page {
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 57f24e2cd19c..0684cc6b17c5 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -53,6 +53,7 @@
#include <linux/sort.h>
#include <linux/io.h> /* vmap_page_range() */
#include <linux/fs_context.h>
+#include <linux/trace_printk.h>
#include <asm/setup.h> /* COMMAND_LINE_SIZE */
diff --git a/kernel/trace/trace_benchmark.c b/kernel/trace/trace_benchmark.c
index e19c32f2a938..740b49c493db 100644
--- a/kernel/trace/trace_benchmark.c
+++ b/kernel/trace/trace_benchmark.c
@@ -3,6 +3,7 @@
#include <linux/module.h>
#include <linux/kthread.h>
#include <linux/trace_clock.h>
+#include <linux/trace_printk.h>
#define CREATE_TRACE_POINTS
#include "trace_benchmark.h"
diff --git a/kernel/trace/trace_events_trigger.c b/kernel/trace/trace_events_trigger.c
index 06b75bcfc7b8..1c1420a4c429 100644
--- a/kernel/trace/trace_events_trigger.c
+++ b/kernel/trace/trace_events_trigger.c
@@ -12,6 +12,7 @@
#include <linux/mutex.h>
#include <linux/slab.h>
#include <linux/rculist.h>
+#include <linux/trace_printk.h>
#include "trace.h"
diff --git a/kernel/trace/trace_functions.c b/kernel/trace/trace_functions.c
index c12795c2fb39..ec725f8b2343 100644
--- a/kernel/trace/trace_functions.c
+++ b/kernel/trace/trace_functions.c
@@ -16,6 +16,7 @@
#include <linux/ftrace.h>
#include <linux/slab.h>
#include <linux/fs.h>
+#include <linux/trace_printk.h>
#include "trace.h"
diff --git a/kernel/trace/trace_printk.c b/kernel/trace/trace_printk.c
index 29f6e95439b6..e49609c97496 100644
--- a/kernel/trace/trace_printk.c
+++ b/kernel/trace/trace_printk.c
@@ -16,6 +16,7 @@
#include <linux/ctype.h>
#include <linux/list.h>
#include <linux/slab.h>
+#include <linux/trace_printk.h>
#include "trace.h"
diff --git a/kernel/trace/trace_selftest.c b/kernel/trace/trace_selftest.c
index d88c44f1dfa5..b6aa5c92f079 100644
--- a/kernel/trace/trace_selftest.c
+++ b/kernel/trace/trace_selftest.c
@@ -6,6 +6,7 @@
#include <linux/kthread.h>
#include <linux/delay.h>
#include <linux/slab.h>
+#include <linux/trace_printk.h>
static inline int trace_valid_entry(struct trace_entry *entry)
{
diff --git a/lib/sys_info.c b/lib/sys_info.c
index f32a06ec9ed4..7ded4e7f3671 100644
--- a/lib/sys_info.c
+++ b/lib/sys_info.c
@@ -10,6 +10,7 @@
#include <linux/sched/debug.h>
#include <linux/string.h>
#include <linux/sysctl.h>
+#include <linux/trace_printk.h>
#include <linux/sys_info.h>
diff --git a/samples/fprobe/fprobe_example.c b/samples/fprobe/fprobe_example.c
index bfe98ce826f3..dfebb1cefb2c 100644
--- a/samples/fprobe/fprobe_example.c
+++ b/samples/fprobe/fprobe_example.c
@@ -17,6 +17,7 @@
#include <linux/fprobe.h>
#include <linux/sched/debug.h>
#include <linux/slab.h>
+#include <linux/trace_printk.h>
#define BACKTRACE_DEPTH 16
#define MAX_SYMBOL_LEN 4096
diff --git a/samples/ftrace/ftrace-direct-modify.c b/samples/ftrace/ftrace-direct-modify.c
index da3a9f2091f5..cb6989f52167 100644
--- a/samples/ftrace/ftrace-direct-modify.c
+++ b/samples/ftrace/ftrace-direct-modify.c
@@ -2,6 +2,7 @@
#include <linux/module.h>
#include <linux/kthread.h>
#include <linux/ftrace.h>
+#include <linux/trace_printk.h>
#if !defined(CONFIG_ARM64) && !defined(CONFIG_PPC32)
#include <asm/asm-offsets.h>
#endif
diff --git a/samples/ftrace/ftrace-direct-multi-modify.c b/samples/ftrace/ftrace-direct-multi-modify.c
index 8f7986d698d8..1b24d53c34c2 100644
--- a/samples/ftrace/ftrace-direct-multi-modify.c
+++ b/samples/ftrace/ftrace-direct-multi-modify.c
@@ -2,6 +2,7 @@
#include <linux/module.h>
#include <linux/kthread.h>
#include <linux/ftrace.h>
+#include <linux/trace_printk.h>
#if !defined(CONFIG_ARM64) && !defined(CONFIG_PPC32)
#include <asm/asm-offsets.h>
#endif
diff --git a/samples/ftrace/ftrace-direct-multi.c b/samples/ftrace/ftrace-direct-multi.c
index db326c81a27d..3c94ecdaf3d5 100644
--- a/samples/ftrace/ftrace-direct-multi.c
+++ b/samples/ftrace/ftrace-direct-multi.c
@@ -4,6 +4,7 @@
#include <linux/mm.h> /* for handle_mm_fault() */
#include <linux/ftrace.h>
#include <linux/sched/stat.h>
+#include <linux/trace_printk.h>
#if !defined(CONFIG_ARM64) && !defined(CONFIG_PPC32)
#include <asm/asm-offsets.h>
#endif
diff --git a/samples/ftrace/ftrace-direct-too.c b/samples/ftrace/ftrace-direct-too.c
index 3d0fa260332d..e4c26db202ce 100644
--- a/samples/ftrace/ftrace-direct-too.c
+++ b/samples/ftrace/ftrace-direct-too.c
@@ -3,6 +3,7 @@
#include <linux/mm.h> /* for handle_mm_fault() */
#include <linux/ftrace.h>
+#include <linux/trace_printk.h>
#if !defined(CONFIG_ARM64) && !defined(CONFIG_PPC32)
#include <asm/asm-offsets.h>
#endif
diff --git a/samples/ftrace/ftrace-direct.c b/samples/ftrace/ftrace-direct.c
index 956834b0d19a..01f3512aec50 100644
--- a/samples/ftrace/ftrace-direct.c
+++ b/samples/ftrace/ftrace-direct.c
@@ -3,6 +3,7 @@
#include <linux/sched.h> /* for wake_up_process() */
#include <linux/ftrace.h>
+#include <linux/trace_printk.h>
#if !defined(CONFIG_ARM64) && !defined(CONFIG_PPC32)
#include <asm/asm-offsets.h>
#endif
diff --git a/samples/trace_printk/trace-printk.c b/samples/trace_printk/trace-printk.c
index cfc159580263..4fc58844aff1 100644
--- a/samples/trace_printk/trace-printk.c
+++ b/samples/trace_printk/trace-printk.c
@@ -2,6 +2,7 @@
#include <linux/module.h>
#include <linux/kthread.h>
#include <linux/irq_work.h>
+#include <linux/trace_printk.h>
/* Must not be static to force gcc to consider these non constant */
char *trace_printk_test_global_str =
diff --git a/sound/hda/common/sysfs.c b/sound/hda/common/sysfs.c
index f8c8483fd5e5..ac382f7063dc 100644
--- a/sound/hda/common/sysfs.c
+++ b/sound/hda/common/sysfs.c
@@ -19,6 +19,7 @@
#include "hda_local.h"
#include <sound/hda_hwdep.h>
#include <sound/minors.h>
+#include <linux/trace_printk.h>
/* hint string pair */
struct hda_hint {
--
2.43.0
^ permalink raw reply related [flat|nested] 28+ messages in thread
* Re: [PATCH v4 7/7] kernel.h: drop trace_printk.h
2025-12-25 17:09 ` [PATCH v4 7/7] kernel.h: drop trace_printk.h Yury Norov (NVIDIA)
@ 2025-12-26 16:58 ` Steven Rostedt
2025-12-27 14:45 ` Andy Shevchenko
2025-12-28 21:31 ` Andrew Morton
2025-12-27 14:50 ` Andy Shevchenko
1 sibling, 2 replies; 28+ messages in thread
From: Steven Rostedt @ 2025-12-26 16:58 UTC (permalink / raw)
To: Yury Norov (NVIDIA)
Cc: Andrew Morton, Masami Hiramatsu, Mathieu Desnoyers,
Andy Shevchenko, Christophe Leroy, Randy Dunlap, Ingo Molnar,
Jani Nikula, Joonas Lahtinen, David Laight, Petr Pavlu,
Andi Shyti, Rodrigo Vivi, Tvrtko Ursulin, Daniel Gomez,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
linux-kernel, intel-gfx, dri-devel, linux-modules,
linux-trace-kernel
On Thu, 25 Dec 2025 12:09:29 -0500
"Yury Norov (NVIDIA)" <yury.norov@gmail.com> wrote:
> The trace_printk.h header is debugging-only by nature, but now it's
> included by almost every compilation unit via kernel.h.
>
> Removing trace_printk.h saves 1.5-2% of compilation time on my
> Ubuntu-derived x86_64/localyesconfig.
>
> There's ~30 files in the codebase, requiring trace_printk.h for
> non-debugging reasons: mostly to disable tracing on panic or under
> similar conditions. Include the header for those explicitly.
>
> This implicitly decouples linux/kernel.h and linux/instruction_pointer.h
> as well, because it has been isolated to trace_printk.h early in the
> series.
>
> Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
I'm still against this patch. It means every time someone adds
trace_printk() they need to add the header for it.
trace_printk() should be as available to the kernel as printk() is. If
there's a place that one can add printk() without adding a header, then
they should be able to add trace_printk() to that same location without
adding any header. If that's not the case, then I'm adding an official
Nacked-by: Steven Rostedt <rostedt@goodmis.org>
I'm fine for trying other ways to speed up the compilation, but removing
full access to trace_printk() isn't one of them.
-- Steve
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v4 7/7] kernel.h: drop trace_printk.h
2025-12-26 16:58 ` Steven Rostedt
@ 2025-12-27 14:45 ` Andy Shevchenko
2025-12-27 15:57 ` Steven Rostedt
2025-12-28 21:31 ` Andrew Morton
1 sibling, 1 reply; 28+ messages in thread
From: Andy Shevchenko @ 2025-12-27 14:45 UTC (permalink / raw)
To: Steven Rostedt
Cc: Yury Norov (NVIDIA), Andrew Morton, Masami Hiramatsu,
Mathieu Desnoyers, Christophe Leroy, Randy Dunlap, Ingo Molnar,
Jani Nikula, Joonas Lahtinen, David Laight, Petr Pavlu,
Andi Shyti, Rodrigo Vivi, Tvrtko Ursulin, Daniel Gomez,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
linux-kernel, intel-gfx, dri-devel, linux-modules,
linux-trace-kernel
On Fri, Dec 26, 2025 at 11:58:48AM -0500, Steven Rostedt wrote:
> On Thu, 25 Dec 2025 12:09:29 -0500
> "Yury Norov (NVIDIA)" <yury.norov@gmail.com> wrote:
>
> > The trace_printk.h header is debugging-only by nature, but now it's
> > included by almost every compilation unit via kernel.h.
> >
> > Removing trace_printk.h saves 1.5-2% of compilation time on my
> > Ubuntu-derived x86_64/localyesconfig.
> >
> > There's ~30 files in the codebase, requiring trace_printk.h for
> > non-debugging reasons: mostly to disable tracing on panic or under
> > similar conditions. Include the header for those explicitly.
> >
> > This implicitly decouples linux/kernel.h and linux/instruction_pointer.h
> > as well, because it has been isolated to trace_printk.h early in the
> > series.
> >
> > Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
>
> I'm still against this patch. It means every time someone adds
> trace_printk() they need to add the header for it.
>
> trace_printk() should be as available to the kernel as printk() is. If
> there's a place that one can add printk() without adding a header, then
> they should be able to add trace_printk() to that same location without
> adding any header. If that's not the case, then I'm adding an official
>
> Nacked-by: Steven Rostedt <rostedt@goodmis.org>
>
> I'm fine for trying other ways to speed up the compilation, but removing
> full access to trace_printk() isn't one of them.
I interpreted this as if the header inclusion should be moved from kernel.h
to printk.h as a compromise that satisfies all (?) stakeholders. Is it possible
approach?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v4 7/7] kernel.h: drop trace_printk.h
2025-12-25 17:09 ` [PATCH v4 7/7] kernel.h: drop trace_printk.h Yury Norov (NVIDIA)
2025-12-26 16:58 ` Steven Rostedt
@ 2025-12-27 14:50 ` Andy Shevchenko
1 sibling, 0 replies; 28+ messages in thread
From: Andy Shevchenko @ 2025-12-27 14:50 UTC (permalink / raw)
To: Yury Norov (NVIDIA)
Cc: Steven Rostedt, Andrew Morton, Masami Hiramatsu,
Mathieu Desnoyers, Christophe Leroy, Randy Dunlap, Ingo Molnar,
Jani Nikula, Joonas Lahtinen, David Laight, Petr Pavlu,
Andi Shyti, Rodrigo Vivi, Tvrtko Ursulin, Daniel Gomez,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
linux-kernel, intel-gfx, dri-devel, linux-modules,
linux-trace-kernel
On Thu, Dec 25, 2025 at 12:09:29PM -0500, Yury Norov (NVIDIA) wrote:
> The trace_printk.h header is debugging-only by nature, but now it's
> included by almost every compilation unit via kernel.h.
>
> Removing trace_printk.h saves 1.5-2% of compilation time on my
> Ubuntu-derived x86_64/localyesconfig.
>
> There's ~30 files in the codebase, requiring trace_printk.h for
> non-debugging reasons: mostly to disable tracing on panic or under
> similar conditions. Include the header for those explicitly.
>
> This implicitly decouples linux/kernel.h and linux/instruction_pointer.h
> as well, because it has been isolated to trace_printk.h early in the
> series.
...
> #include <linux/pagevec.h>
> #include <linux/scatterlist.h>
> #include <linux/workqueue.h>
> +#include <linux/trace_printk.h>
I believe 't' is followed by 'w' and not vise versa.
...
> index 20b3cb29cfff..549fdeaf4508 100644
> --- a/drivers/gpu/drm/i915/i915_gem.h
> +++ b/drivers/gpu/drm/i915/i915_gem.h
> @@ -27,6 +27,7 @@
>
> #include <linux/bug.h>
> #include <linux/types.h>
> +#include <linux/trace_printk.h>
In the similar way 'r' then 'y'.
...
Please, double check these and the rest.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v4 7/7] kernel.h: drop trace_printk.h
2025-12-27 14:45 ` Andy Shevchenko
@ 2025-12-27 15:57 ` Steven Rostedt
2025-12-27 19:35 ` Yury Norov
0 siblings, 1 reply; 28+ messages in thread
From: Steven Rostedt @ 2025-12-27 15:57 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Yury Norov (NVIDIA), Andrew Morton, Masami Hiramatsu,
Mathieu Desnoyers, Christophe Leroy, Randy Dunlap, Ingo Molnar,
Jani Nikula, Joonas Lahtinen, David Laight, Petr Pavlu,
Andi Shyti, Rodrigo Vivi, Tvrtko Ursulin, Daniel Gomez,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
linux-kernel, intel-gfx, dri-devel, linux-modules,
linux-trace-kernel
On Sat, 27 Dec 2025 16:45:47 +0200
Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> > I'm fine for trying other ways to speed up the compilation, but removing
> > full access to trace_printk() isn't one of them.
>
> I interpreted this as if the header inclusion should be moved from kernel.h
> to printk.h as a compromise that satisfies all (?) stakeholders. Is it possible
> approach?
I'm fine with putting the include of trace_printk.h into printk.h. If
you remove printk.h from kernel.h I would expect a lot more people to
complain about it. Including Linus himself.
-- Steve
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v4 7/7] kernel.h: drop trace_printk.h
2025-12-27 15:57 ` Steven Rostedt
@ 2025-12-27 19:35 ` Yury Norov
2025-12-27 21:27 ` Steven Rostedt
0 siblings, 1 reply; 28+ messages in thread
From: Yury Norov @ 2025-12-27 19:35 UTC (permalink / raw)
To: Steven Rostedt
Cc: Andy Shevchenko, Andrew Morton, Masami Hiramatsu,
Mathieu Desnoyers, Christophe Leroy, Randy Dunlap, Ingo Molnar,
Jani Nikula, Joonas Lahtinen, David Laight, Petr Pavlu,
Andi Shyti, Rodrigo Vivi, Tvrtko Ursulin, Daniel Gomez,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
linux-kernel, intel-gfx, dri-devel, linux-modules,
linux-trace-kernel
On Sat, Dec 27, 2025 at 10:57:01AM -0500, Steven Rostedt wrote:
> On Sat, 27 Dec 2025 16:45:47 +0200
> Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
>
> > > I'm fine for trying other ways to speed up the compilation, but removing
> > > full access to trace_printk() isn't one of them.
OK, then let's keep trace_printk() available for kernel.h users.
Andrew, can you take the first 6 patches of the series, if no other
objections?
> > I interpreted this as if the header inclusion should be moved from kernel.h
> > to printk.h as a compromise that satisfies all (?) stakeholders. Is it possible
> > approach?
>
> I'm fine with putting the include of trace_printk.h into printk.h. If
> you remove printk.h from kernel.h I would expect a lot more people to
> complain about it. Including Linus himself.
The difference is that printk() is not a debugging tool. It is used
widely to report errors and info messages. Normally, I want to cleanup
all debugging code from my module after finishing development. If
trace_printk.h will be a part of printk.h, there's always a chance to
miss trace_printk() somewhere. I'd prefer to keep them separate.
Thanks,
Yury
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v4 7/7] kernel.h: drop trace_printk.h
2025-12-27 19:35 ` Yury Norov
@ 2025-12-27 21:27 ` Steven Rostedt
0 siblings, 0 replies; 28+ messages in thread
From: Steven Rostedt @ 2025-12-27 21:27 UTC (permalink / raw)
To: Yury Norov
Cc: Andy Shevchenko, Andrew Morton, Masami Hiramatsu,
Mathieu Desnoyers, Christophe Leroy, Randy Dunlap, Ingo Molnar,
Jani Nikula, Joonas Lahtinen, David Laight, Petr Pavlu,
Andi Shyti, Rodrigo Vivi, Tvrtko Ursulin, Daniel Gomez,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
linux-kernel, intel-gfx, dri-devel, linux-modules,
linux-trace-kernel
On Sat, 27 Dec 2025 14:35:52 -0500
Yury Norov <yury.norov@gmail.com> wrote:
> The difference is that printk() is not a debugging tool.
Several developers will disagree with you. In fact, Linus has said he uses
printk() as his preferred debugging tool!
The only reason to have printk.h in kernel.h is because it *is* used for
debugging! If it wasn't used for debugging, then you could simply add
printk.h for those places that needed to use printk(). But because it is
one of the most common debugging tools, having it in kernel.h is useful, as
you don't want to have to add #include <printk.h> every time you added a
printk() for debugging purposes (same is true for trace_printk()).
Yes, it is also used for information. But if that's all it was used for,
then it wouldn't need to be in kernel.h. It could be a normal header file
that anything that needed to print information would have to include.
-- Steve
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v4 7/7] kernel.h: drop trace_printk.h
2025-12-26 16:58 ` Steven Rostedt
2025-12-27 14:45 ` Andy Shevchenko
@ 2025-12-28 21:31 ` Andrew Morton
2025-12-29 16:17 ` Steven Rostedt
1 sibling, 1 reply; 28+ messages in thread
From: Andrew Morton @ 2025-12-28 21:31 UTC (permalink / raw)
To: Steven Rostedt
Cc: Yury Norov (NVIDIA), Masami Hiramatsu, Mathieu Desnoyers,
Andy Shevchenko, Christophe Leroy, Randy Dunlap, Ingo Molnar,
Jani Nikula, Joonas Lahtinen, David Laight, Petr Pavlu,
Andi Shyti, Rodrigo Vivi, Tvrtko Ursulin, Daniel Gomez,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
linux-kernel, intel-gfx, dri-devel, linux-modules,
linux-trace-kernel
On Fri, 26 Dec 2025 11:58:48 -0500 Steven Rostedt <rostedt@goodmis.org> wrote:
> On Thu, 25 Dec 2025 12:09:29 -0500
> "Yury Norov (NVIDIA)" <yury.norov@gmail.com> wrote:
>
> > The trace_printk.h header is debugging-only by nature, but now it's
> > included by almost every compilation unit via kernel.h.
> >
> > Removing trace_printk.h saves 1.5-2% of compilation time on my
> > Ubuntu-derived x86_64/localyesconfig.
> >
> > There's ~30 files in the codebase, requiring trace_printk.h for
> > non-debugging reasons: mostly to disable tracing on panic or under
> > similar conditions. Include the header for those explicitly.
> >
> > This implicitly decouples linux/kernel.h and linux/instruction_pointer.h
> > as well, because it has been isolated to trace_printk.h early in the
> > series.
> >
> > Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
>
> I'm still against this patch. It means every time someone adds
> trace_printk() they need to add the header for it.
>
> trace_printk() should be as available to the kernel as printk() is.
um, why? trace_printk is used 1% as often as is printk. Seems
reasonable to include a header file to access such a rarely-used(!) and
specialized thing?
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v4 7/7] kernel.h: drop trace_printk.h
2025-12-28 21:31 ` Andrew Morton
@ 2025-12-29 16:17 ` Steven Rostedt
2025-12-29 16:41 ` Danilo Krummrich
` (3 more replies)
0 siblings, 4 replies; 28+ messages in thread
From: Steven Rostedt @ 2025-12-29 16:17 UTC (permalink / raw)
To: Andrew Morton
Cc: Yury Norov (NVIDIA), Masami Hiramatsu, Mathieu Desnoyers,
Andy Shevchenko, Christophe Leroy, Randy Dunlap, Ingo Molnar,
Jani Nikula, Joonas Lahtinen, David Laight, Petr Pavlu,
Andi Shyti, Rodrigo Vivi, Tvrtko Ursulin, Daniel Gomez,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
linux-kernel, intel-gfx, dri-devel, linux-modules,
linux-trace-kernel
On Sun, 28 Dec 2025 13:31:50 -0800
Andrew Morton <akpm@linux-foundation.org> wrote:
> > trace_printk() should be as available to the kernel as printk() is.
>
> um, why? trace_printk is used 1% as often as is printk. Seems
> reasonable to include a header file to access such a rarely-used(!) and
> specialized thing?
It will waste a lot of kernel developers time. Go to conferences and talk
with developers. trace_printk() is now one of the most common ways to debug
your code. Having to add "#include <linux/trace_printk.h>" in every file
that you use trace_printk() (and after your build fails because you forgot
to include that file **WILL** slow down kernel debugging for hundreds of
developers! It *is* used more than printk() for debugging today. Because
it's fast and can be used in any context (NMI, interrupt handlers, etc).
But sure, if you want to save the few minutes that is added to "make
allyesconfig" by sacrificing minutes of kernel developer's time. Go ahead
and make this change.
I don't know how much you debug and develop today, but lots of people I
talk to at conferences thank me for trace_printk() because it makes
debugging their code so much easier.
The "shotgun" approach is very common. That is, you add:
trace_printk("%s:%d\n", __func__, __LINE__);
all over your code to find out where things are going wrong. With the
persistent ring buffer, you can even extract that information after a
crash and reboot.
There's very few instances of it in the kernel because I made it that way.
If you add a trace_printk() in the kernel, you get the banner:
**********************************************************
** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE **
** **
** trace_printk() being used. Allocating extra memory. **
** **
** This means that this is a DEBUG kernel and it is **
** unsafe for production use. **
** **
** If you see this message and you are not debugging **
** the kernel, report this immediately to your vendor! **
** **
** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE **
**********************************************************
in your dmesg.
I've been recommending people that if you find a "trace_printk()" useful,
you should convert it into a normal TRACE_EVENT() for submission. Which
many developers have done.
Yes, it's not in your kernel, but it is in several other people's kernels
as they develop it. And adding a requirement that they need to include a
header file for every place they add it (and then have to remember to
remove that header file when they are done debugging) is going to waste
more precious time that kernel developers don't have much of.
-- Steve
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v4 7/7] kernel.h: drop trace_printk.h
2025-12-29 16:17 ` Steven Rostedt
@ 2025-12-29 16:41 ` Danilo Krummrich
2025-12-29 17:19 ` Borislav Petkov
` (2 subsequent siblings)
3 siblings, 0 replies; 28+ messages in thread
From: Danilo Krummrich @ 2025-12-29 16:41 UTC (permalink / raw)
To: Steven Rostedt
Cc: Andrew Morton, Yury Norov (NVIDIA), Masami Hiramatsu,
Mathieu Desnoyers, Andy Shevchenko, Christophe Leroy,
Randy Dunlap, Ingo Molnar, Jani Nikula, Joonas Lahtinen,
David Laight, Petr Pavlu, Andi Shyti, Rodrigo Vivi,
Tvrtko Ursulin, Daniel Gomez, Greg Kroah-Hartman,
Rafael J. Wysocki, linux-kernel, intel-gfx, dri-devel,
linux-modules, linux-trace-kernel
On Mon Dec 29, 2025 at 5:17 PM CET, Steven Rostedt wrote:
> It will waste a lot of kernel developers time. Go to conferences and talk
> with developers. trace_printk() is now one of the most common ways to debug
> your code. Having to add "#include <linux/trace_printk.h>" in every file
> that you use trace_printk() (and after your build fails because you forgot
> to include that file **WILL** slow down kernel debugging for hundreds of
> developers! It *is* used more than printk() for debugging today. Because
> it's fast and can be used in any context (NMI, interrupt handlers, etc).
I strongly agree with this. I heavly use trace_printk() for debugging for a long
time and have recommended it to dozens of people that all have been very
thankful for it -- especially when it comes to debugging race conditions on a
tough timing, where a normal printk() simply "fixes" the race.
Having to include additional headers would be very painful, especially when
debugging large code bases with lots of files. For instance, one of the
components I maintain is the nouveau driver with 773 C files and 1390 files
overall.
I suppose it would be fair to argue that such codebases usually have their own
common header files that could be reused, but even in that case, I’d consider
the ergonomic cost too high.
- Danilo
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v4 7/7] kernel.h: drop trace_printk.h
2025-12-29 16:17 ` Steven Rostedt
2025-12-29 16:41 ` Danilo Krummrich
@ 2025-12-29 17:19 ` Borislav Petkov
2025-12-29 22:25 ` Mathieu Desnoyers
2026-01-03 0:50 ` Joel Fernandes
3 siblings, 0 replies; 28+ messages in thread
From: Borislav Petkov @ 2025-12-29 17:19 UTC (permalink / raw)
To: Steven Rostedt
Cc: Andrew Morton, Yury Norov (NVIDIA), Masami Hiramatsu,
Mathieu Desnoyers, Andy Shevchenko, Christophe Leroy,
Randy Dunlap, Ingo Molnar, Jani Nikula, Joonas Lahtinen,
David Laight, Petr Pavlu, Andi Shyti, Rodrigo Vivi,
Tvrtko Ursulin, Daniel Gomez, Greg Kroah-Hartman,
Rafael J. Wysocki, Danilo Krummrich, linux-kernel, intel-gfx,
dri-devel, linux-modules, linux-trace-kernel
On Mon, Dec 29, 2025 at 11:17:48AM -0500, Steven Rostedt wrote:
> But sure, if you want to save the few minutes that is added to "make
> allyesconfig"
Nah, it is
"Removing trace_printk.h saves 1.5-2% of compilation time on my
Ubuntu-derived x86_64/localyesconfig"
which is:
localyesconfig - Update current config converting local mods to core
and which makes me wonder - who does that?
What are we actually optimizing here?
And 1-2% at that.
I don't see how this outweighs the goodness of using trace_printk()
everywhere.
So that's a NO on that patch from me too.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v4 7/7] kernel.h: drop trace_printk.h
2025-12-29 16:17 ` Steven Rostedt
2025-12-29 16:41 ` Danilo Krummrich
2025-12-29 17:19 ` Borislav Petkov
@ 2025-12-29 22:25 ` Mathieu Desnoyers
2025-12-30 8:55 ` Andy Shevchenko
2026-01-03 0:50 ` Joel Fernandes
3 siblings, 1 reply; 28+ messages in thread
From: Mathieu Desnoyers @ 2025-12-29 22:25 UTC (permalink / raw)
To: Steven Rostedt, Andrew Morton
Cc: Yury Norov (NVIDIA), Masami Hiramatsu, Andy Shevchenko,
Christophe Leroy, Randy Dunlap, Ingo Molnar, Jani Nikula,
Joonas Lahtinen, David Laight, Petr Pavlu, Andi Shyti,
Rodrigo Vivi, Tvrtko Ursulin, Daniel Gomez, Greg Kroah-Hartman,
Rafael J. Wysocki, Danilo Krummrich, linux-kernel, intel-gfx,
dri-devel, linux-modules, linux-trace-kernel
On 2025-12-29 11:17, Steven Rostedt wrote:
> On Sun, 28 Dec 2025 13:31:50 -0800
> Andrew Morton <akpm@linux-foundation.org> wrote:
>
>>> trace_printk() should be as available to the kernel as printk() is.
>>
>> um, why? trace_printk is used 1% as often as is printk. Seems
>> reasonable to include a header file to access such a rarely-used(!) and
>> specialized thing?
[...]
> Yes, it's not in your kernel, but it is in several other people's kernels
> as they develop it. And adding a requirement that they need to include a
> header file for every place they add it (and then have to remember to
> remove that header file when they are done debugging) is going to waste
> more precious time that kernel developers don't have much of.
I agree with Steven. trace_printk() needs to stay convenient to use for
kernel developers. Part of this convenience comes from not having to
include additional header files by hand. It has been around for
16 years and documented as such in kernel documentation [1],
LWN articles [2], and conference presentation material. Changing
this would lead to confusion for people trying to use the feature.
I personally use trace_printk() to sprinkle temporary debug-style
trace events in frequently executed kernel code I need to follow
carefully.
One possible compromise would be to move it to its own header file,
and introduce a CONFIG_TRACE_PRINTK Kconfig option (default Y) that
would surround an include from linux/kernel.h with a preprocessor
conditional. But please make sure the default stays as it is today:
include the trace printk header by default.
Thanks,
Mathieu
[1] Debugging the kernel using Ftrace - part 1 https://lwn.net/Articles/365835/
[2] Documentation/trace/ftrace.txt
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v4 7/7] kernel.h: drop trace_printk.h
2025-12-29 22:25 ` Mathieu Desnoyers
@ 2025-12-30 8:55 ` Andy Shevchenko
2025-12-30 14:21 ` Mathieu Desnoyers
0 siblings, 1 reply; 28+ messages in thread
From: Andy Shevchenko @ 2025-12-30 8:55 UTC (permalink / raw)
To: Mathieu Desnoyers
Cc: Steven Rostedt, Andrew Morton, Yury Norov (NVIDIA),
Masami Hiramatsu, Christophe Leroy, Randy Dunlap, Ingo Molnar,
Jani Nikula, Joonas Lahtinen, David Laight, Petr Pavlu,
Andi Shyti, Rodrigo Vivi, Tvrtko Ursulin, Daniel Gomez,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
linux-kernel, intel-gfx, dri-devel, linux-modules,
linux-trace-kernel
On Mon, Dec 29, 2025 at 05:25:08PM -0500, Mathieu Desnoyers wrote:
...
> One possible compromise would be to move it to its own header file,
> and introduce a CONFIG_TRACE_PRINTK Kconfig option (default Y) that
> would surround an include from linux/kernel.h with a preprocessor
> conditional. But please make sure the default stays as it is today:
> include the trace printk header by default.
"by default" where exactly? The problem is that kernel.h is a total mess and
it's included in a lot of mysterious ways (indirectly), and in C you _must_
include a header anyway for a custom API, just define *which* one.
Based on the Steven's first replies I see a compromise in having it inside
printk.h. If you want to debug something with printf() (in general) the same
header should provide all species. Do you agree?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v4 7/7] kernel.h: drop trace_printk.h
2025-12-30 8:55 ` Andy Shevchenko
@ 2025-12-30 14:21 ` Mathieu Desnoyers
2025-12-30 16:18 ` Yury Norov
0 siblings, 1 reply; 28+ messages in thread
From: Mathieu Desnoyers @ 2025-12-30 14:21 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Steven Rostedt, Andrew Morton, Yury Norov (NVIDIA),
Masami Hiramatsu, Christophe Leroy, Randy Dunlap, Ingo Molnar,
Jani Nikula, Joonas Lahtinen, David Laight, Petr Pavlu,
Andi Shyti, Rodrigo Vivi, Tvrtko Ursulin, Daniel Gomez,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
linux-kernel, intel-gfx, dri-devel, linux-modules,
linux-trace-kernel
On 2025-12-30 03:55, Andy Shevchenko wrote:
> On Mon, Dec 29, 2025 at 05:25:08PM -0500, Mathieu Desnoyers wrote:
>
> ...
>
>> One possible compromise would be to move it to its own header file,
>> and introduce a CONFIG_TRACE_PRINTK Kconfig option (default Y) that
>> would surround an include from linux/kernel.h with a preprocessor
>> conditional. But please make sure the default stays as it is today:
>> include the trace printk header by default.
>
> "by default" where exactly? The problem is that kernel.h is a total mess and
> it's included in a lot of mysterious ways (indirectly), and in C you _must_
> include a header anyway for a custom API, just define *which* one.
This patch series moves the guts of trace_printk into its own header
file, which reduces clutter. So that's already progress. :)
>
> Based on the Steven's first replies I see a compromise in having it inside
> printk.h. If you want to debug something with printf() (in general) the same
> header should provide all species. Do you agree?
I don't have a strong opinion about including trace_printk.h from either
kernel.h or printk.h. As long as it's still included by a default kernel
config the same way it has been documented/used since 2009.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v4 7/7] kernel.h: drop trace_printk.h
2025-12-30 14:21 ` Mathieu Desnoyers
@ 2025-12-30 16:18 ` Yury Norov
2025-12-30 16:46 ` Steven Rostedt
0 siblings, 1 reply; 28+ messages in thread
From: Yury Norov @ 2025-12-30 16:18 UTC (permalink / raw)
To: Mathieu Desnoyers
Cc: Andy Shevchenko, Steven Rostedt, Andrew Morton, Masami Hiramatsu,
Christophe Leroy, Randy Dunlap, Ingo Molnar, Jani Nikula,
Joonas Lahtinen, David Laight, Petr Pavlu, Andi Shyti,
Rodrigo Vivi, Tvrtko Ursulin, Daniel Gomez, Greg Kroah-Hartman,
Rafael J. Wysocki, Danilo Krummrich, linux-kernel, intel-gfx,
dri-devel, linux-modules, linux-trace-kernel
On Tue, Dec 30, 2025 at 09:21:00AM -0500, Mathieu Desnoyers wrote:
> On 2025-12-30 03:55, Andy Shevchenko wrote:
> > On Mon, Dec 29, 2025 at 05:25:08PM -0500, Mathieu Desnoyers wrote:
> >
> > ...
> >
> > > One possible compromise would be to move it to its own header file,
> > > and introduce a CONFIG_TRACE_PRINTK Kconfig option (default Y) that
> > > would surround an include from linux/kernel.h with a preprocessor
> > > conditional.
We already have CONFIG_TRACING, and everything in the new
trace_printk.h is conditional on it. We can protect the header in
kernel.h with the same config.
> > > But please make sure the default stays as it is today:
> > > include the trace printk header by default.
> >
> > "by default" where exactly?
Seemingly nowhere.
> > The problem is that kernel.h is a total mess and
> > it's included in a lot of mysterious ways (indirectly),
Yes!
> > and in C you _must_
> > include a header anyway for a custom API, just define *which* one.
>
> This patch series moves the guts of trace_printk into its own header
> file, which reduces clutter. So that's already progress. :)
>
> >
> > Based on the Steven's first replies I see a compromise in having it inside
> > printk.h. If you want to debug something with printf() (in general) the same
> > header should provide all species. Do you agree?
It may sound logical, but I don't like this idea. Printk() is used
for debugging by everyone, but its main goal is to communicate to
userspace and between different parts of the kernel. Notice how all
debugging and development API in linux/pritnk.h is protected with the
corresponding ifdefery.
Contrary to that, trace_printk() is a purely debugging feature. There's
no use for it after the debugging is done. (Or I missed something?)
Everyone admits that kernel.h is a mess. Particularly, it's a mess of
development and production features. So, moving trace_printk() from an
already messy kernel.h to a less messy printk.h - to me it looks like
spreading the mess.
> I don't have a strong opinion about including trace_printk.h from either
> kernel.h or printk.h. As long as it's still included by a default kernel
> config the same way it has been documented/used since 2009.
Can you please point to the documentation and quote the exact piece
stating that? Git history points to the commit 40ada30f9621f from Ingo
that decouples tracers from DEBUG_KERNEL, and the following 422d3c7a577
from Kosaki that force-enables the new TRACING_SUPPORT regardless of
the DEBUG_KERNEL state.
To me, decoupling tracing from DEBUG_KERNEL looks accidental rather than
intentional. So maybe simply restore that dependency?
Currently, even with tinyconfig, DEBUG_KERNEL is enabled (via EXPERT).
And even if EXPERT and DEBUG_KERNEL are off, tracers are still enabled.
This doesn't look right...
Thanks,
Yury
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v4 7/7] kernel.h: drop trace_printk.h
2025-12-30 16:18 ` Yury Norov
@ 2025-12-30 16:46 ` Steven Rostedt
0 siblings, 0 replies; 28+ messages in thread
From: Steven Rostedt @ 2025-12-30 16:46 UTC (permalink / raw)
To: Yury Norov
Cc: Mathieu Desnoyers, Andy Shevchenko, Andrew Morton,
Masami Hiramatsu, Christophe Leroy, Randy Dunlap, Ingo Molnar,
Jani Nikula, Joonas Lahtinen, David Laight, Petr Pavlu,
Andi Shyti, Rodrigo Vivi, Tvrtko Ursulin, Daniel Gomez,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
linux-kernel, intel-gfx, dri-devel, linux-modules,
linux-trace-kernel
On Tue, 30 Dec 2025 11:18:37 -0500
Yury Norov <yury.norov@gmail.com> wrote:
> On Tue, Dec 30, 2025 at 09:21:00AM -0500, Mathieu Desnoyers wrote:
> > On 2025-12-30 03:55, Andy Shevchenko wrote:
> > > On Mon, Dec 29, 2025 at 05:25:08PM -0500, Mathieu Desnoyers wrote:
> > >
> > > ...
> > >
> > > > One possible compromise would be to move it to its own header file,
> > > > and introduce a CONFIG_TRACE_PRINTK Kconfig option (default Y) that
> > > > would surround an include from linux/kernel.h with a preprocessor
> > > > conditional.
>
> We already have CONFIG_TRACING, and everything in the new
> trace_printk.h is conditional on it. We can protect the header in
> kernel.h with the same config.
Tracing is used in production all the time. So I think we can have a new
config just for trace_printk(). I was actually thinking of adding a
CONFIG_HIDE_TRACE_PRINTK, with the description of:
trace_printk() is an extremely powerful utility to debug and develop
kernel code. It is defined in kernel.h so that it can be easily accessed
during development or having to debug existing code.
But trace_printk() is not to be included in the final result, and having
it in kernel.h during normal builds where the builder has no plans of
debugging the kernel causes wasted cycles and time in compiling the kernel.
By saying yes here, the include of trace_printk() macros will be hidden
from kernel.h and help speed up the compile.
If you do not plan on debugging this kernel, say Y
And then have in kernel.h:
#ifndef CONFIG_HIDE_TRACE_PRINTK
# include <linux/trace_printk.h>
#endif
This also means it gets set for allyesconfig builds, which I doubt anyone
wants to debug anyway.
>
> > > > But please make sure the default stays as it is today:
> > > > include the trace printk header by default.
> > >
> > > "by default" where exactly?
>
> Seemingly nowhere.
>
> > > The problem is that kernel.h is a total mess and
> > > it's included in a lot of mysterious ways (indirectly),
>
> Yes!
>
> > > and in C you _must_
> > > include a header anyway for a custom API, just define *which* one.
> >
> > This patch series moves the guts of trace_printk into its own header
> > file, which reduces clutter. So that's already progress. :)
> >
> > >
> > > Based on the Steven's first replies I see a compromise in having it inside
> > > printk.h. If you want to debug something with printf() (in general) the same
> > > header should provide all species. Do you agree?
>
> It may sound logical, but I don't like this idea. Printk() is used
> for debugging by everyone, but its main goal is to communicate to
> userspace and between different parts of the kernel. Notice how all
> debugging and development API in linux/pritnk.h is protected with the
> corresponding ifdefery.
>
> Contrary to that, trace_printk() is a purely debugging feature. There's
> no use for it after the debugging is done. (Or I missed something?)
I actually agree with you here. I don't think adding trace_printk.h into
printk.h is appropriate. I only said that anywhere you can add a printk()
for debugging, you should also be able to add trace_printk(). I believe
kernel.h is the appropriate place for both.
>
> Everyone admits that kernel.h is a mess. Particularly, it's a mess of
> development and production features. So, moving trace_printk() from an
> already messy kernel.h to a less messy printk.h - to me it looks like
> spreading the mess.
>
> > I don't have a strong opinion about including trace_printk.h from either
> > kernel.h or printk.h. As long as it's still included by a default kernel
> > config the same way it has been documented/used since 2009.
>
> Can you please point to the documentation and quote the exact piece
> stating that? Git history points to the commit 40ada30f9621f from Ingo
> that decouples tracers from DEBUG_KERNEL, and the following 422d3c7a577
> from Kosaki that force-enables the new TRACING_SUPPORT regardless of
> the DEBUG_KERNEL state.
>
> To me, decoupling tracing from DEBUG_KERNEL looks accidental rather than
> intentional. So maybe simply restore that dependency?
Absolutely not. Tracing is used to debug production kernels, and things
like live kernel patching also depend on it, not to mention BPF.
>
> Currently, even with tinyconfig, DEBUG_KERNEL is enabled (via EXPERT).
> And even if EXPERT and DEBUG_KERNEL are off, tracers are still enabled.
> This doesn't look right...
Looks fine to me.
-- Steve
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v4 7/7] kernel.h: drop trace_printk.h
2025-12-29 16:17 ` Steven Rostedt
` (2 preceding siblings ...)
2025-12-29 22:25 ` Mathieu Desnoyers
@ 2026-01-03 0:50 ` Joel Fernandes
2026-01-03 12:57 ` Andy Shevchenko
3 siblings, 1 reply; 28+ messages in thread
From: Joel Fernandes @ 2026-01-03 0:50 UTC (permalink / raw)
To: Steven Rostedt
Cc: Andrew Morton, Yury Norov (NVIDIA), Masami Hiramatsu,
Mathieu Desnoyers, Andy Shevchenko, Christophe Leroy,
Randy Dunlap, Ingo Molnar, Jani Nikula, Joonas Lahtinen,
David Laight, Petr Pavlu, Andi Shyti, Rodrigo Vivi,
Tvrtko Ursulin, Daniel Gomez, Greg Kroah-Hartman,
Rafael J. Wysocki, Danilo Krummrich, linux-kernel, intel-gfx,
dri-devel, linux-modules, linux-trace-kernel
On Mon, Dec 29, 2025 at 11:17:48AM -0500, Steven Rostedt wrote:
> On Sun, 28 Dec 2025 13:31:50 -0800
> Andrew Morton <akpm@linux-foundation.org> wrote:
>
> > > trace_printk() should be as available to the kernel as printk() is.
> >
> > um, why? trace_printk is used 1% as often as is printk. Seems
> > reasonable to include a header file to access such a rarely-used(!) and
> > specialized thing?
>
> It will waste a lot of kernel developers time. Go to conferences and talk
> with developers. trace_printk() is now one of the most common ways to debug
> your code. Having to add "#include <linux/trace_printk.h>" in every file
> that you use trace_printk() (and after your build fails because you forgot
> to include that file **WILL** slow down kernel debugging for hundreds of
> developers! It *is* used more than printk() for debugging today. Because
> it's fast and can be used in any context (NMI, interrupt handlers, etc).
>
> But sure, if you want to save the few minutes that is added to "make
> allyesconfig" by sacrificing minutes of kernel developer's time. Go ahead
> and make this change.
>
> I don't know how much you debug and develop today, but lots of people I
> talk to at conferences thank me for trace_printk() because it makes
> debugging their code so much easier.
>
> The "shotgun" approach is very common. That is, you add:
>
> trace_printk("%s:%d\n", __func__, __LINE__);
>
> all over your code to find out where things are going wrong. With the
> persistent ring buffer, you can even extract that information after a
> crash and reboot.
I use trace_printk() all the time for kernel, particularly RCU development.
One of the key usecases I have is dumping traces on panic (with panic on warn
and stop tracing on warn enabled). This is extremely useful since I can add
custom tracing and dump traces when rare conditions occur. I fixed several
bugs with this technique.
I also recommend keeping it convenient to use.
thanks,
- Joel
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v4 7/7] kernel.h: drop trace_printk.h
2026-01-03 0:50 ` Joel Fernandes
@ 2026-01-03 12:57 ` Andy Shevchenko
2026-01-03 14:22 ` Yury Norov
2026-01-03 15:36 ` Joel Fernandes
0 siblings, 2 replies; 28+ messages in thread
From: Andy Shevchenko @ 2026-01-03 12:57 UTC (permalink / raw)
To: Joel Fernandes
Cc: Steven Rostedt, Andrew Morton, Yury Norov (NVIDIA),
Masami Hiramatsu, Mathieu Desnoyers, Christophe Leroy,
Randy Dunlap, Ingo Molnar, Jani Nikula, Joonas Lahtinen,
David Laight, Petr Pavlu, Andi Shyti, Rodrigo Vivi,
Tvrtko Ursulin, Daniel Gomez, Greg Kroah-Hartman,
Rafael J. Wysocki, Danilo Krummrich, linux-kernel, intel-gfx,
dri-devel, linux-modules, linux-trace-kernel
On Fri, Jan 02, 2026 at 07:50:59PM -0500, Joel Fernandes wrote:
> On Mon, Dec 29, 2025 at 11:17:48AM -0500, Steven Rostedt wrote:
...
> I use trace_printk() all the time for kernel, particularly RCU development.
> One of the key usecases I have is dumping traces on panic (with panic on warn
> and stop tracing on warn enabled). This is extremely useful since I can add
> custom tracing and dump traces when rare conditions occur. I fixed several
> bugs with this technique.
>
> I also recommend keeping it convenient to use.
Okay, you know C, please share your opinion what header is the best to hold the
trace_printk.h to be included.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v4 7/7] kernel.h: drop trace_printk.h
2026-01-03 12:57 ` Andy Shevchenko
@ 2026-01-03 14:22 ` Yury Norov
2026-01-03 15:36 ` Joel Fernandes
1 sibling, 0 replies; 28+ messages in thread
From: Yury Norov @ 2026-01-03 14:22 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Joel Fernandes, Steven Rostedt, Andrew Morton, Masami Hiramatsu,
Mathieu Desnoyers, Christophe Leroy, Randy Dunlap, Ingo Molnar,
Jani Nikula, Joonas Lahtinen, David Laight, Petr Pavlu,
Andi Shyti, Rodrigo Vivi, Tvrtko Ursulin, Daniel Gomez,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
linux-kernel, intel-gfx, dri-devel, linux-modules,
linux-trace-kernel
On Sat, Jan 03, 2026 at 02:57:58PM +0200, Andy Shevchenko wrote:
> On Fri, Jan 02, 2026 at 07:50:59PM -0500, Joel Fernandes wrote:
> > On Mon, Dec 29, 2025 at 11:17:48AM -0500, Steven Rostedt wrote:
>
> ...
>
> > I use trace_printk() all the time for kernel, particularly RCU development.
> > One of the key usecases I have is dumping traces on panic (with panic on warn
> > and stop tracing on warn enabled). This is extremely useful since I can add
> > custom tracing and dump traces when rare conditions occur. I fixed several
> > bugs with this technique.
> >
> > I also recommend keeping it convenient to use.
>
> Okay, you know C, please share your opinion what header is the best to hold the
> trace_printk.h to be included.
What if we include it on Makefile level, similarly to how W=1 works?
make D=1 // trace_printk() is available
make D=0 // trace_printk() is not available
make // trace_printk() is not available
Where D stands for debugging.
D=1 may be a default setting if you prefer, but the most important is
that every compilation unit will have an access to debugging without
polluting core headers.
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v4 7/7] kernel.h: drop trace_printk.h
2026-01-03 12:57 ` Andy Shevchenko
2026-01-03 14:22 ` Yury Norov
@ 2026-01-03 15:36 ` Joel Fernandes
2026-01-04 0:20 ` Andy Shevchenko
1 sibling, 1 reply; 28+ messages in thread
From: Joel Fernandes @ 2026-01-03 15:36 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Steven Rostedt, Andrew Morton, Yury Norov, Masami Hiramatsu,
Mathieu Desnoyers, Christophe Leroy, Randy Dunlap, Ingo Molnar,
Jani Nikula, Joonas Lahtinen, David Laight, Petr Pavlu,
Andi Shyti, Vivi Rodrigo, Tvrtko Ursulin, Daniel Gomez,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org,
dri-devel@lists.freedesktop.org, linux-modules@vger.kernel.org,
linux-trace-kernel@vger.kernel.org
> On Jan 3, 2026, at 7:58 AM, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
>
> On Fri, Jan 02, 2026 at 07:50:59PM -0500, Joel Fernandes wrote:
>> On Mon, Dec 29, 2025 at 11:17:48AM -0500, Steven Rostedt wrote:
>
> ...
>
>> I use trace_printk() all the time for kernel, particularly RCU development.
>> One of the key usecases I have is dumping traces on panic (with panic on warn
>> and stop tracing on warn enabled). This is extremely useful since I can add
>> custom tracing and dump traces when rare conditions occur. I fixed several
>> bugs with this technique.
>>
>> I also recommend keeping it convenient to use.
>
> Okay, you know C, please share your opinion what header is the best to hold the
> trace_printk.h to be included.
I do not think it is necessary to move it.
- Joel
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH v4 7/7] kernel.h: drop trace_printk.h
2026-01-03 15:36 ` Joel Fernandes
@ 2026-01-04 0:20 ` Andy Shevchenko
0 siblings, 0 replies; 28+ messages in thread
From: Andy Shevchenko @ 2026-01-04 0:20 UTC (permalink / raw)
To: Joel Fernandes
Cc: Steven Rostedt, Andrew Morton, Yury Norov, Masami Hiramatsu,
Mathieu Desnoyers, Christophe Leroy, Randy Dunlap, Ingo Molnar,
Jani Nikula, Joonas Lahtinen, David Laight, Petr Pavlu,
Andi Shyti, Vivi Rodrigo, Tvrtko Ursulin, Daniel Gomez,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org,
dri-devel@lists.freedesktop.org, linux-modules@vger.kernel.org,
linux-trace-kernel@vger.kernel.org
On Sat, Jan 03, 2026 at 03:36:44PM +0000, Joel Fernandes wrote:
> > On Jan 3, 2026, at 7:58 AM, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> > On Fri, Jan 02, 2026 at 07:50:59PM -0500, Joel Fernandes wrote:
> >> On Mon, Dec 29, 2025 at 11:17:48AM -0500, Steven Rostedt wrote:
...
> >> I use trace_printk() all the time for kernel, particularly RCU development.
> >> One of the key usecases I have is dumping traces on panic (with panic on warn
> >> and stop tracing on warn enabled). This is extremely useful since I can add
> >> custom tracing and dump traces when rare conditions occur. I fixed several
> >> bugs with this technique.
> >>
> >> I also recommend keeping it convenient to use.
> >
> > Okay, you know C, please share your opinion what header is the best to hold the
> > trace_printk.h to be included.
>
> I do not think it is necessary to move it.
I'm not talking about move, I'm talking about the C 101 thingy. Any custom API
should be included before use, otherwise compiler won't see it. Which header do
you want to include to have this API being provided? Note, it's really bad
situation right now with the header to be included implicitly via non-obvious
or obscure path. The discussion moved as far as I see it towards the finding a
good place for the trace_printk.h.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 28+ messages in thread
end of thread, other threads:[~2026-01-04 0:21 UTC | newest]
Thread overview: 28+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-12-25 17:09 [PATCH v4 0/7] Unload linux/kernel.h Yury Norov (NVIDIA)
2025-12-25 17:09 ` [PATCH v4 1/7] kernel.h: drop STACK_MAGIC macro Yury Norov (NVIDIA)
2025-12-25 17:09 ` [PATCH v4 2/7] moduleparam: include required headers explicitly Yury Norov (NVIDIA)
2025-12-25 17:09 ` [PATCH v4 3/7] kernel.h: move VERIFY_OCTAL_PERMISSIONS() to sysfs.h Yury Norov (NVIDIA)
2025-12-25 17:09 ` [PATCH v4 4/7] kernel.h: include linux/instruction_pointer.h explicitly Yury Norov (NVIDIA)
2025-12-25 17:09 ` [PATCH v4 5/7] tracing: Remove size parameter in __trace_puts() Yury Norov (NVIDIA)
2025-12-25 17:09 ` [PATCH v4 6/7] tracing: move tracing declarations from kernel.h to a dedicated header Yury Norov (NVIDIA)
2025-12-25 17:09 ` [PATCH v4 7/7] kernel.h: drop trace_printk.h Yury Norov (NVIDIA)
2025-12-26 16:58 ` Steven Rostedt
2025-12-27 14:45 ` Andy Shevchenko
2025-12-27 15:57 ` Steven Rostedt
2025-12-27 19:35 ` Yury Norov
2025-12-27 21:27 ` Steven Rostedt
2025-12-28 21:31 ` Andrew Morton
2025-12-29 16:17 ` Steven Rostedt
2025-12-29 16:41 ` Danilo Krummrich
2025-12-29 17:19 ` Borislav Petkov
2025-12-29 22:25 ` Mathieu Desnoyers
2025-12-30 8:55 ` Andy Shevchenko
2025-12-30 14:21 ` Mathieu Desnoyers
2025-12-30 16:18 ` Yury Norov
2025-12-30 16:46 ` Steven Rostedt
2026-01-03 0:50 ` Joel Fernandes
2026-01-03 12:57 ` Andy Shevchenko
2026-01-03 14:22 ` Yury Norov
2026-01-03 15:36 ` Joel Fernandes
2026-01-04 0:20 ` Andy Shevchenko
2025-12-27 14:50 ` Andy Shevchenko
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).