Unload linux/kernel.h

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 <[email protected]>

Acked-by Randy Dunlap <[email protected]>

Acked-by Jani Nikula <[email protected]>

Reviewed-by Christophe Leroy (CS GROUP) <[email protected]>

Signed-off-by Yury Norov (NVIDIA) <[email protected]>

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 <[email protected]>

Acked-by Randy Dunlap <[email protected]>

Acked-by Jani Nikula <[email protected]>

Reviewed-by Christophe Leroy (CS GROUP) <[email protected]>

Signed-off-by Yury Norov (NVIDIA) <[email protected]>

---
 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(-)

drivers/gpu/drm/i915/gt/selftest_ring_submission.c +1 -0

index 87ceb0f374b6..600333ae6c8c 100644
@@ -3,6 +3,7 @@
  * Copyright © 2020 Intel Corporation
  */
 
+#include "i915_selftest.h"
 #include "intel_engine_pm.h"
 #include "selftests/igt_flush_test.h"
 

drivers/gpu/drm/i915/i915_selftest.h +2 -0

index bdf3e22c0a34..72922028f4ba 100644
@@ -26,6 +26,8 @@
 
 #include <linux/types.h>
 
+#define STACK_MAGIC	0xdeadbeef
+
 struct pci_dev;
 struct drm_i915_private;
 

include/linux/kernel.h +0 -2

index 5b46924fdff5..61d63c57bc2d 100644
@@ -40,8 +40,6 @@
 
 #include <uapi/linux/kernel.h>
 
-#define STACK_MAGIC	0xdeadbeef
-
 struct completion;
 struct user;
 

Signature · 1 line

2.43.0

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, except for removing a few 'extern's.

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, except for removing a few 'extern's.

Quoted 4 lines · On Fri, 5 Dec 2025 12:52:35 -0500 "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.

Quoted 6 lines

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, except for removing a few 'extern's.

This one blows up my x86_64 allmodconfig, gcc-15.2.0:

Quoted 4 lines · On Fri, 5 Dec 2025 12:52:35 -0500 "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.

Quoted 6 lines

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, except for removing a few 'extern's.

This one blows up my x86_64 allmodconfig, gcc-15.2.0:

In file included from ./include/linux/string.h:386,

                 from ./include/linux/trace_printk.h:9,
                 from ./include/linux/kernel.h:34,
                 from arch/x86/purgatory/purgatory.c:12:

./include/linux/fortify-string.h:626:63: error: expected identifier or '(' before '{' token
626 | p_size_field, q_size_field, op) ({ \
| ^
./include/linux/fortify-string.h:694:27: note: in expansion of macro '__fortify_memcpy_chk'

  694 | #define memmove(p, q, s)  __fortify_memcpy_chk(p, q, s,                 \
      |                           ^~~~~~~~~~~~~~~~~~~~
arch/x86/purgatory/../boot/string.h:11:7: note: in expansion of macro 'memmove'
   11 | void *memmove(void *dst, const void *src, size_t len);
      |       ^~~~~~~
./include/linux/fortify-string.h:258:9: error: expected identifier or '(' before '__builtin_choose_expr'
  258 |         __builtin_choose_expr(__is_constexpr(__builtin_strlen(p)),      \
      |         ^~~~~~~~~~~~~~~~~~~~~
arch/x86/purgatory/../boot/string.h:23:15: note: in expansion of macro 'strlen'
   23 | extern size_t strlen(const char *s);
      |               ^~~~~~

make[4]: *** [scripts/Makefile.build:287: arch/x86/purgatory/purgatory.o] Error 1 make[3]: *** [scripts/Makefile.build:556: arch/x86/purgatory] Error 2 make[2]: *** [scripts/Makefile.build:556: arch/x86] Error 2
make[1]: *** [/usr/src/25/Makefile:2054: .] Error 2
make: *** [Makefile:248: __sub-make] Error 2

[adding Kees]

Quoted 6 lines · Andrew Morton

Quoted 4 lines · On Fri, 5 Dec 2025 12:52:35 -0500 "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.

Quoted 6 lines

Quoted 6 lines

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, except for removing a few 'extern's.

Hm, for a pure move, this shouldn't be necessary. Anyway, not using FORTIFY in purgatory.o fixes this build error.
Or maybe there's a better answer.

---
 arch/x86/purgatory/Makefile |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Quoted 27 lines · Randy Dunlap

[adding Kees]

Quoted 6 lines · Andrew Morton

Quoted 4 lines · On Fri, 5 Dec 2025 12:52:35 -0500 "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.

Quoted 6 lines

Quoted 6 lines

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, except for removing a few 'extern's.

Hm, for a pure move, this shouldn't be necessary. Anyway, not using FORTIFY in purgatory.o fixes this build error.
Or maybe there's a better answer.

---
 arch/x86/purgatory/Makefile |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/x86/purgatory/Makefile PURGATORY_CFLAGS_REMOVE += $(CC_FLAGS_C · line 68

Quoted 8 lines

arch/x86/purgatory/Makefile +1 -1

@@ -62,7 +62,7 @@ PURGATORY_CFLAGS_REMOVE		+= $(CC_FLAGS_C
 endif
 
 CFLAGS_REMOVE_purgatory.o	+= $(PURGATORY_CFLAGS_REMOVE)
-CFLAGS_purgatory.o		+= $(PURGATORY_CFLAGS)
+CFLAGS_purgatory.o		+= $(PURGATORY_CFLAGS) -D__NO_FORTIFY
 
 CFLAGS_REMOVE_sha256.o		+= $(PURGATORY_CFLAGS_REMOVE)
 CFLAGS_sha256.o			+= $(PURGATORY_CFLAGS)

That happened because the new trace_printk.h includes string.h for strlen(), so all kernel.h users now indirectly include it, and it causes, seemingly, a circular dependency if FORTIFY is enabled.

A fix would be dropping trace_printk.h from kernel.h, or switching the only user of string.h, trace_puts(), to __builtin_strlen().

Notice, Andy has concerned about this on the previous round, and also suggested __builtin_strlen():

        https://lkml.org/lkml/2025/12/3/910

I deem to drop trace_printk.h from kernel.h - it is more aligned with the idea of unloading the header. The original motivation to keep trace_printk.h in kernel.h was just because a similar printk.h is living there. But after all, this is a purely debugging header, so no need for almost every C file to bear debugging stuff.

I can actually do both - switch to an intrinsic and drop the header.

Guys, please let me know what do you thing.

I deem to drop trace_printk.h from kernel.h - it is more aligned with the idea of unloading the header. The original motivation to keep trace_printk.h in kernel.h was just because a similar printk.h is living there. But after all, this is a purely debugging header, so no need for almost every C file to bear debugging stuff.

Quoted 5 lines · On Wed, 17 Dec 2025 22:59:33 -0500 Yury Norov <[email protected]> wrote:

I deem to drop trace_printk.h from kernel.h - it is more aligned with the idea of unloading the header. The original motivation to keep trace_printk.h in kernel.h was just because a similar printk.h is living there. But after all, this is a purely debugging header, so no need for almost every C file to bear debugging stuff.

It is a big deal for debugging stuff. A lot of developers debug their code with trace_printk(), and do the "shotgun approach", where they cut and paste trace_printk()s all over their code in several files. Having to now add:

  #include <linux/trace_printk.h>

whenever a trace_printk() is added is going to be a big PITA and slow down all debugging efforts.

Quoted 13 lines · On Thu, 18 Dec 2025 12:33:49 -0500 Steven Rostedt <[email protected]> wrote:

Quoted 5 lines · On Wed, 17 Dec 2025 22:59:33 -0500 Yury Norov <[email protected]> wrote:

I deem to drop trace_printk.h from kernel.h - it is more aligned with the idea of unloading the header. The original motivation to keep trace_printk.h in kernel.h was just because a similar printk.h is living there. But after all, this is a purely debugging header, so no need for almost every C file to bear debugging stuff.

It is a big deal for debugging stuff. A lot of developers debug their code with trace_printk(), and do the "shotgun approach", where they cut and paste trace_printk()s all over their code in several files. Having to now add:

Quoted 5 lines

  #include <linux/trace_printk.h>

whenever a trace_printk() is added is going to be a big PITA and slow down all debugging efforts.

I don't actually remember why I had __trace_puts() pass in the size. I could change it to:

include/linux/kernel.h +2 -2

index 5b46924fdff5..d5a939b8c391 100644
@@ -331,10 +331,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);
 

kernel/trace/trace.c +3 -4

index e575956ef9b5..686741edb803 100644
@@ -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;

kernel/trace/trace.h +1 -1

index b6d42fe06115..de4e6713b84e 100644
@@ -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)	\

Which removes the strlen() altogether.

-- Steve

Quoted 2 lines

I don't actually remember why I had __trace_puts() pass in the size. I could change it to:

This is the best approach. I'll schedule it for v4. Would you like me to take it as-is, or you'd send a patch?

Quoted 6 lines · On Thu, 18 Dec 2025 15:33:47 -0500 Yury Norov <[email protected]> wrote:

Quoted 2 lines

I don't actually remember why I had __trace_puts() pass in the size. I could change it to:

This is the best approach. I'll schedule it for v4. Would you like me to take it as-is, or you'd send a patch?

Let me send an official patch.

Quoted 10 lines · On Thu, 18 Dec 2025 16:25:42 -0500 Steven Rostedt <[email protected]> wrote:

Quoted 6 lines · On Thu, 18 Dec 2025 15:33:47 -0500 Yury Norov <[email protected]> wrote:

Quoted 2 lines

I don't actually remember why I had __trace_puts() pass in the size. I could change it to:

This is the best approach. I'll schedule it for v4. Would you like me to take it as-is, or you'd send a patch?

Quoted 2 lines

Let me send an official patch.

You can find it here (I Cc'd you too). Feel free to add it to your patch set.

https://lore.kernel.org/all/[email protected]/

Quoted 5 lines · On Wed, 17 Dec 2025 22:59:33 -0500 Yury Norov <[email protected]> wrote:

I deem to drop trace_printk.h from kernel.h - it is more aligned with the idea of unloading the header. The original motivation to keep trace_printk.h in kernel.h was just because a similar printk.h is living there. But after all, this is a purely debugging header, so no need for almost every C file to bear debugging stuff.

It is a big deal for debugging stuff. A lot of developers debug their code with trace_printk(), and do the "shotgun approach", where they cut and paste trace_printk()s all over their code in several files. Having to now add:

  #include <linux/trace_printk.h>

whenever a trace_printk() is added is going to be a big PITA and slow down all debugging efforts.

Quoted 13 lines · Steven Rostedt

Quoted 5 lines · On Wed, 17 Dec 2025 22:59:33 -0500 Yury Norov <[email protected]> wrote:

I deem to drop trace_printk.h from kernel.h - it is more aligned with the idea of unloading the header. The original motivation to keep trace_printk.h in kernel.h was just because a similar printk.h is living there. But after all, this is a purely debugging header, so no need for almost every C file to bear debugging stuff.

It is a big deal for debugging stuff. A lot of developers debug their code with trace_printk(), and do the "shotgun approach", where they cut and paste trace_printk()s all over their code in several files. Having to now add:

Quoted 4 lines

  #include <linux/trace_printk.h>

whenever a trace_printk() is added is going to be a big PITA and slow down all debugging efforts.

Eh? Maybe a PITA, but surely not a big one.
Slow down "all debugging efforts?"
Please cut down on the hyperbole.