[PATCH 0/3] Unload linux/kernel.h

[PATCH 0/3] Unload linux/kernel.h

[Yury Norov (NVIDIA)]

kernel.h hosts declarations that can be placed better.

Yury Norov (NVIDIA) (3):
  kernel.h: drop STACK_MAGIC macro
  kernel.h: move VERIFY_OCTAL_PERMISSIONS() to sysfs.h
  tracing: move tracing declarations from kernel.h to a dedicated header

 MAINTAINERS                       |   1 +
 drivers/gpu/drm/i915/i915_utils.h |   2 +
 include/linux/kernel.h            | 209 +-----------------------------
 include/linux/moduleparam.h       |   2 +-
 include/linux/sysfs.h             |  13 ++
 include/linux/tracing.h           | 203 +++++++++++++++++++++++++++++
 6 files changed, 221 insertions(+), 209 deletions(-)
 create mode 100644 include/linux/tracing.h

-- 
2.43.0

[PATCH 1/3] kernel.h: drop STACK_MAGIC macro

[Yury Norov (NVIDIA)]

The macro is only used by i915. Move it to a local header and drop from
the kernel.h.

Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
---
 drivers/gpu/drm/i915/i915_utils.h | 2 ++
 include/linux/kernel.h            | 2 --
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_utils.h b/drivers/gpu/drm/i915/i915_utils.h
index a0c892e4c40d..6c197e968305 100644
--- a/drivers/gpu/drm/i915/i915_utils.h
+++ b/drivers/gpu/drm/i915/i915_utils.h
@@ -32,6 +32,8 @@
 #include <linux/workqueue.h>
 #include <linux/sched/clock.h>
 
+#define STACK_MAGIC	0xdeadbeef
+
 #ifdef CONFIG_X86
 #include <asm/hypervisor.h>
 #endif
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

Re: [PATCH 1/3] kernel.h: drop STACK_MAGIC macro

[Andy Shevchenko]

On Sat, Nov 29, 2025 at 02:53:00PM -0500, Yury Norov (NVIDIA) wrote:
> The macro is only used by i915. Move it to a local header and drop from
> the kernel.h.

Agree, if one wants to reinstate it, there should be better place for it
(something related to kasan?).

FWIW,
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 1/3] kernel.h: drop STACK_MAGIC macro

[Randy Dunlap]

On 11/29/25 12:32 PM, Andy Shevchenko wrote:
> On Sat, Nov 29, 2025 at 02:53:00PM -0500, Yury Norov (NVIDIA) wrote:
>> The macro is only used by i915. Move it to a local header and drop from
>> the kernel.h.
> 
> Agree, if one wants to reinstate it, there should be better place for it
> (something related to kasan?).

or <linux/poison.h>

> FWIW,
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

Acked-by: Randy Dunlap <rdunlap@infradead.org>

-- 
~Randy

Re: [PATCH 1/3] kernel.h: drop STACK_MAGIC macro

[Jani Nikula]

On Sat, 29 Nov 2025, "Yury Norov (NVIDIA)" <yury.norov@gmail.com> wrote:
> The macro is only used by i915. Move it to a local header and drop from
> the kernel.h.
>
> Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
> ---
>  drivers/gpu/drm/i915/i915_utils.h | 2 ++
>  include/linux/kernel.h            | 2 --
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_utils.h b/drivers/gpu/drm/i915/i915_utils.h
> index a0c892e4c40d..6c197e968305 100644
> --- a/drivers/gpu/drm/i915/i915_utils.h
> +++ b/drivers/gpu/drm/i915/i915_utils.h

i915_utils.h is on a diet itself. STACK_MAGIC is only used in selftests,
please put this in i915_selftest.h.

I guess also need to include that from gt/selftest_ring_submission.c,
the only one that uses STACK_MAGIC but doesn't include i915_selftest.h.

BR,
Jani.


> @@ -32,6 +32,8 @@
>  #include <linux/workqueue.h>
>  #include <linux/sched/clock.h>
>  
> +#define STACK_MAGIC	0xdeadbeef
> +
>  #ifdef CONFIG_X86
>  #include <asm/hypervisor.h>
>  #endif
> 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;

-- 
Jani Nikula, Intel

Re: [PATCH 1/3] kernel.h: drop STACK_MAGIC macro

[Andi Shyti]

Hi Jani,

On Mon, Dec 01, 2025 at 09:46:47AM +0200, Jani Nikula wrote:
> On Sat, 29 Nov 2025, "Yury Norov (NVIDIA)" <yury.norov@gmail.com> wrote:
> > The macro is only used by i915. Move it to a local header and drop from
> > the kernel.h.
> >
> > Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
> > ---
> >  drivers/gpu/drm/i915/i915_utils.h | 2 ++
> >  include/linux/kernel.h            | 2 --
> >  2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_utils.h b/drivers/gpu/drm/i915/i915_utils.h
> > index a0c892e4c40d..6c197e968305 100644
> > --- a/drivers/gpu/drm/i915/i915_utils.h
> > +++ b/drivers/gpu/drm/i915/i915_utils.h
> 
> i915_utils.h is on a diet itself. STACK_MAGIC is only used in selftests,
> please put this in i915_selftest.h.
> 
> I guess also need to include that from gt/selftest_ring_submission.c,
> the only one that uses STACK_MAGIC but doesn't include i915_selftest.h.

Doing this cleanups is a bit out of the scope of this patch.
Given that the patch itself has quite a good consensus, let move
it forward and I can take care of the i915 cleanup once it gets
merged.

Andi

Re: [PATCH 1/3] kernel.h: drop STACK_MAGIC macro

[Yury Norov]

On Tue, Dec 02, 2025 at 09:58:19PM +0100, Andi Shyti wrote:
> Hi Jani,
> 
> On Mon, Dec 01, 2025 at 09:46:47AM +0200, Jani Nikula wrote:
> > On Sat, 29 Nov 2025, "Yury Norov (NVIDIA)" <yury.norov@gmail.com> wrote:
> > > The macro is only used by i915. Move it to a local header and drop from
> > > the kernel.h.
> > >
> > > Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
> > > ---
> > >  drivers/gpu/drm/i915/i915_utils.h | 2 ++
> > >  include/linux/kernel.h            | 2 --
> > >  2 files changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_utils.h b/drivers/gpu/drm/i915/i915_utils.h
> > > index a0c892e4c40d..6c197e968305 100644
> > > --- a/drivers/gpu/drm/i915/i915_utils.h
> > > +++ b/drivers/gpu/drm/i915/i915_utils.h
> > 
> > i915_utils.h is on a diet itself. STACK_MAGIC is only used in selftests,
> > please put this in i915_selftest.h.
> > 
> > I guess also need to include that from gt/selftest_ring_submission.c,
> > the only one that uses STACK_MAGIC but doesn't include i915_selftest.h.
> 
> Doing this cleanups is a bit out of the scope of this patch.
> Given that the patch itself has quite a good consensus, let move
> it forward and I can take care of the i915 cleanup once it gets
> merged.

I'm already testing it in my tree:

https://github.com/norov/linux/tree/sm1

If everything is fine, I'll submit v2 with this change, otherwise will
schedule it for future improvements.

Re: [PATCH 1/3] kernel.h: drop STACK_MAGIC macro

[Jani Nikula]

On Tue, 02 Dec 2025, Yury Norov <yury.norov@gmail.com> wrote:
> On Tue, Dec 02, 2025 at 09:58:19PM +0100, Andi Shyti wrote:
>> Hi Jani,
>> 
>> On Mon, Dec 01, 2025 at 09:46:47AM +0200, Jani Nikula wrote:
>> > On Sat, 29 Nov 2025, "Yury Norov (NVIDIA)" <yury.norov@gmail.com> wrote:
>> > > The macro is only used by i915. Move it to a local header and drop from
>> > > the kernel.h.
>> > >
>> > > Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
>> > > ---
>> > >  drivers/gpu/drm/i915/i915_utils.h | 2 ++
>> > >  include/linux/kernel.h            | 2 --
>> > >  2 files changed, 2 insertions(+), 2 deletions(-)
>> > >
>> > > diff --git a/drivers/gpu/drm/i915/i915_utils.h b/drivers/gpu/drm/i915/i915_utils.h
>> > > index a0c892e4c40d..6c197e968305 100644
>> > > --- a/drivers/gpu/drm/i915/i915_utils.h
>> > > +++ b/drivers/gpu/drm/i915/i915_utils.h
>> > 
>> > i915_utils.h is on a diet itself. STACK_MAGIC is only used in selftests,
>> > please put this in i915_selftest.h.
>> > 
>> > I guess also need to include that from gt/selftest_ring_submission.c,
>> > the only one that uses STACK_MAGIC but doesn't include i915_selftest.h.
>> 
>> Doing this cleanups is a bit out of the scope of this patch.
>> Given that the patch itself has quite a good consensus, let move
>> it forward and I can take care of the i915 cleanup once it gets
>> merged.
>
> I'm already testing it in my tree:
>
> https://github.com/norov/linux/tree/sm1
>
> If everything is fine, I'll submit v2 with this change, otherwise will
> schedule it for future improvements.

I had a look,

Acked-by: Jani Nikula <jani.nikula@intel.com>



-- 
Jani Nikula, Intel

Re: [PATCH 1/3] kernel.h: drop STACK_MAGIC macro

[Christophe Leroy (CS GROUP)]

Le 29/11/2025 à 20:53, Yury Norov (NVIDIA) a écrit :
> The macro is only used by i915. Move it to a local header and drop from
> the kernel.h.

At the begining of the git history we have:

$ git grep STACK_MAGIC 1da177e4c3f41
1da177e4c3f41:arch/h8300/kernel/traps.c:        if (STACK_MAGIC != 
*(unsigned long *)((unsigned long)current+PAGE_SIZE))
1da177e4c3f41:arch/m68k/mac/macints.c:          if (STACK_MAGIC != 
*(unsigned long *)current->kernel_stack_page)
1da177e4c3f41:include/linux/kernel.h:#define STACK_MAGIC        0xdeadbeef

Would be good to know the history of its usage over time.

I see:
- Removed from m68k by 3cd53b14e7c4 ("m68k/mac: Improve NMI handler")
- Removed from h8300 by 1c4b5ecb7ea1 ("remove the h8300 architecture")
- Started being used in i915 selftest by 250f8c8140ac ("drm/i915/gtt: 
Read-only pages for insert_entries on bdw+")

Christophe

> 
> Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
> ---
>   drivers/gpu/drm/i915/i915_utils.h | 2 ++
>   include/linux/kernel.h            | 2 --
>   2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_utils.h b/drivers/gpu/drm/i915/i915_utils.h
> index a0c892e4c40d..6c197e968305 100644
> --- a/drivers/gpu/drm/i915/i915_utils.h
> +++ b/drivers/gpu/drm/i915/i915_utils.h
> @@ -32,6 +32,8 @@
>   #include <linux/workqueue.h>
>   #include <linux/sched/clock.h>
>   
> +#define STACK_MAGIC	0xdeadbeef
> +
>   #ifdef CONFIG_X86
>   #include <asm/hypervisor.h>
>   #endif
> 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;
>   

Re: [PATCH 1/3] kernel.h: drop STACK_MAGIC macro

[Yury Norov]

On Mon, Dec 01, 2025 at 10:38:01AM +0100, Christophe Leroy (CS GROUP) wrote:
> 
> 
> Le 29/11/2025 à 20:53, Yury Norov (NVIDIA) a écrit :
> > The macro is only used by i915. Move it to a local header and drop from
> > the kernel.h.
> 
> At the begining of the git history we have:
> 
> $ git grep STACK_MAGIC 1da177e4c3f41
> 1da177e4c3f41:arch/h8300/kernel/traps.c:        if (STACK_MAGIC !=
> *(unsigned long *)((unsigned long)current+PAGE_SIZE))
> 1da177e4c3f41:arch/m68k/mac/macints.c:          if (STACK_MAGIC !=
> *(unsigned long *)current->kernel_stack_page)
> 1da177e4c3f41:include/linux/kernel.h:#define STACK_MAGIC        0xdeadbeef
> 
> Would be good to know the history of its usage over time.
> 
> I see:
> - Removed from m68k by 3cd53b14e7c4 ("m68k/mac: Improve NMI handler")
> - Removed from h8300 by 1c4b5ecb7ea1 ("remove the h8300 architecture")
> - Started being used in i915 selftest by 250f8c8140ac ("drm/i915/gtt:
> Read-only pages for insert_entries on bdw+")

STACK_MAGIC was added in 1994 in 1.0.2.  It was indeed used in a couple
of places in core subsystems back then to detect stack corruption. But
since that people invented better ways to guard stacks.

You can check commit 4914d770dec4 in this project:

https://archive.org/details/git-history-of-linux

Re: [PATCH 1/3] kernel.h: drop STACK_MAGIC macro

[Andy Shevchenko]

On Mon, Dec 01, 2025 at 09:50:31PM -0500, Yury Norov wrote:
> On Mon, Dec 01, 2025 at 10:38:01AM +0100, Christophe Leroy (CS GROUP) wrote:
> > Le 29/11/2025 à 20:53, Yury Norov (NVIDIA) a écrit :

...

> You can check commit 4914d770dec4 in this project:
> 
> https://archive.org/details/git-history-of-linux

Side note: we have history/history.git tree on kernel.org, and,
if anyone wants to check, it is handy.

Each of the history tree has its own pros and cons:
https://stackoverflow.com/a/51901211/2511795

-- 
With Best Regards,
Andy Shevchenko

[PATCH 2/3] kernel.h: move VERIFY_OCTAL_PERMISSIONS() to sysfs.h

[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.

Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
---
 include/linux/kernel.h      | 12 ------------
 include/linux/moduleparam.h |  2 +-
 include/linux/sysfs.h       | 13 +++++++++++++
 3 files changed, 14 insertions(+), 13 deletions(-)

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 6907aedc4f74..4e390a84a8bc 100644
--- a/include/linux/moduleparam.h
+++ b/include/linux/moduleparam.h
@@ -4,7 +4,7 @@
 /* (C) Copyright 2001, 2002 Rusty Russell IBM Corporation */
 #include <linux/init.h>
 #include <linux/stringify.h>
-#include <linux/kernel.h>
+#include <linux/sysfs.h>
 
 /*
  * The maximum module name length, including the NUL byte.
diff --git a/include/linux/sysfs.h b/include/linux/sysfs.h
index 9a25a2911652..15ee3ef33991 100644
--- a/include/linux/sysfs.h
+++ b/include/linux/sysfs.h
@@ -798,4 +798,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

Re: [PATCH 2/3] kernel.h: move VERIFY_OCTAL_PERMISSIONS() to sysfs.h

[Andy Shevchenko]

On Sat, Nov 29, 2025 at 02:53:01PM -0500, Yury Norov (NVIDIA) wrote:
> The macro is related to sysfs, but is defined in kernel.h. Move it to
> the proper header, and unload the generic kernel.h.

Tough guy :-)
I hope it builds well in your case.

FWIW,
https://lore.kernel.org/lkml/20220603172101.49950-1-andriy.shevchenko@linux.intel.com/
https://lore.kernel.org/lkml/20240212115500.2078463-1-max.kellermann@ionos.com/
https://lore.kernel.org/lkml/20240215093646.3265823-1-max.kellermann@ionos.com/

Assuming it builds in allmodconfig, allyesconfig on x86_32/64 and arm/64
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 2/3] kernel.h: move VERIFY_OCTAL_PERMISSIONS() to sysfs.h

[Andy Shevchenko]

On Sat, Nov 29, 2025 at 10:24:55PM +0200, Andy Shevchenko wrote:
> On Sat, Nov 29, 2025 at 02:53:01PM -0500, Yury Norov (NVIDIA) wrote:
> > The macro is related to sysfs, but is defined in kernel.h. Move it to
> > the proper header, and unload the generic kernel.h.
> 
> Tough guy :-)
> I hope it builds well in your case.
> 
> FWIW,
> https://lore.kernel.org/lkml/20220603172101.49950-1-andriy.shevchenko@linux.intel.com/
> https://lore.kernel.org/lkml/20240212115500.2078463-1-max.kellermann@ionos.com/
> https://lore.kernel.org/lkml/20240215093646.3265823-1-max.kellermann@ionos.com/
> 
> Assuming it builds in allmodconfig, allyesconfig on x86_32/64 and arm/64
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

Actually, one thing should be fixed, i.e.
Documentation/filesystems/sysfs.rst:123:Note as stated in include/linux/kernel.h "OTHER_WRITABLE? ...

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 2/3] kernel.h: move VERIFY_OCTAL_PERMISSIONS() to sysfs.h

[Andy Shevchenko]

On Sat, Nov 29, 2025 at 10:34:02PM +0200, Andy Shevchenko wrote:
> On Sat, Nov 29, 2025 at 10:24:55PM +0200, Andy Shevchenko wrote:
> > On Sat, Nov 29, 2025 at 02:53:01PM -0500, Yury Norov (NVIDIA) wrote:
> > > The macro is related to sysfs, but is defined in kernel.h. Move it to
> > > the proper header, and unload the generic kernel.h.
> > 
> > Tough guy :-)
> > I hope it builds well in your case.
> > 
> > FWIW,
> > https://lore.kernel.org/lkml/20220603172101.49950-1-andriy.shevchenko@linux.intel.com/
> > https://lore.kernel.org/lkml/20240212115500.2078463-1-max.kellermann@ionos.com/
> > https://lore.kernel.org/lkml/20240215093646.3265823-1-max.kellermann@ionos.com/
> > 
> > Assuming it builds in allmodconfig, allyesconfig on x86_32/64 and arm/64
> > Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> 
> Actually, one thing should be fixed, i.e.
> Documentation/filesystems/sysfs.rst:123:Note as stated in include/linux/kernel.h "OTHER_WRITABLE? ...

And just in case, look into
https://lore.kernel.org/r/20251126214709.2322314-1-andriy.shevchenko@linux.intel.com

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 2/3] kernel.h: move VERIFY_OCTAL_PERMISSIONS() to sysfs.h

[Yury Norov]

On Sat, Nov 29, 2025 at 10:35:54PM +0200, Andy Shevchenko wrote:
> On Sat, Nov 29, 2025 at 10:34:02PM +0200, Andy Shevchenko wrote:
> > On Sat, Nov 29, 2025 at 10:24:55PM +0200, Andy Shevchenko wrote:
> > > On Sat, Nov 29, 2025 at 02:53:01PM -0500, Yury Norov (NVIDIA) wrote:
> > > > The macro is related to sysfs, but is defined in kernel.h. Move it to
> > > > the proper header, and unload the generic kernel.h.
> > > 
> > > Tough guy :-)
> > > I hope it builds well in your case.
> > > 
> > > FWIW,
> > > https://lore.kernel.org/lkml/20220603172101.49950-1-andriy.shevchenko@linux.intel.com/
> > > https://lore.kernel.org/lkml/20240212115500.2078463-1-max.kellermann@ionos.com/
> > > https://lore.kernel.org/lkml/20240215093646.3265823-1-max.kellermann@ionos.com/
> > > 
> > > Assuming it builds in allmodconfig, allyesconfig on x86_32/64 and arm/64
> > > Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > 
> > Actually, one thing should be fixed, i.e.
> > Documentation/filesystems/sysfs.rst:123:Note as stated in include/linux/kernel.h "OTHER_WRITABLE? ...
> 
> And just in case, look into
> https://lore.kernel.org/r/20251126214709.2322314-1-andriy.shevchenko@linux.intel.com

Sure. Please find attached.

From 8b08bfd1d4b885bffb67c548d17d98760ca06e76 Mon Sep 17 00:00:00 2001
From: "Yury Norov (NVIDIA)" <yury.norov@gmail.com>
Date: Sun, 30 Nov 2025 12:50:11 -0500
Subject: [PATCH] sysfs: Align update documentation

This series moves VERIFY_OCTAL_PERMISSIONS() from linux/kernel.h to
linux/sysfs.h. Update documentation accordingly

Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
---
 Documentation/filesystems/sysfs.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

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".
 
-- 
2.43.0

Re: [PATCH 2/3] kernel.h: move VERIFY_OCTAL_PERMISSIONS() to sysfs.h

[Andy Shevchenko]

On Sun, Nov 30, 2025 at 12:56:05PM -0500, Yury Norov wrote:
> On Sat, Nov 29, 2025 at 10:35:54PM +0200, Andy Shevchenko wrote:
> > On Sat, Nov 29, 2025 at 10:34:02PM +0200, Andy Shevchenko wrote:
> > > On Sat, Nov 29, 2025 at 10:24:55PM +0200, Andy Shevchenko wrote:
> > > > On Sat, Nov 29, 2025 at 02:53:01PM -0500, Yury Norov (NVIDIA) wrote:
> > > > > The macro is related to sysfs, but is defined in kernel.h. Move it to
> > > > > the proper header, and unload the generic kernel.h.
> > > > 
> > > > Tough guy :-)
> > > > I hope it builds well in your case.
> > > > 
> > > > FWIW,
> > > > https://lore.kernel.org/lkml/20220603172101.49950-1-andriy.shevchenko@linux.intel.com/
> > > > https://lore.kernel.org/lkml/20240212115500.2078463-1-max.kellermann@ionos.com/
> > > > https://lore.kernel.org/lkml/20240215093646.3265823-1-max.kellermann@ionos.com/
> > > > 
> > > > Assuming it builds in allmodconfig, allyesconfig on x86_32/64 and arm/64
> > > > Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > > 
> > > Actually, one thing should be fixed, i.e.
> > > Documentation/filesystems/sysfs.rst:123:Note as stated in include/linux/kernel.h "OTHER_WRITABLE? ...
> > 
> > And just in case, look into
> > https://lore.kernel.org/r/20251126214709.2322314-1-andriy.shevchenko@linux.intel.com
> 
> Sure. Please find attached.

Just fold this into your patch.

Thanks!

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 2/3] kernel.h: move VERIFY_OCTAL_PERMISSIONS() to sysfs.h

[Randy Dunlap]

On 11/29/25 12:24 PM, Andy Shevchenko wrote:
> On Sat, Nov 29, 2025 at 02:53:01PM -0500, Yury Norov (NVIDIA) wrote:
>> The macro is related to sysfs, but is defined in kernel.h. Move it to
>> the proper header, and unload the generic kernel.h.
> 
> Tough guy :-)
> I hope it builds well in your case.
> 
> FWIW,
> https://lore.kernel.org/lkml/20220603172101.49950-1-andriy.shevchenko@linux.intel.com/
> https://lore.kernel.org/lkml/20240212115500.2078463-1-max.kellermann@ionos.com/
> https://lore.kernel.org/lkml/20240215093646.3265823-1-max.kellermann@ionos.com/
> 
> Assuming it builds in allmodconfig, allyesconfig on x86_32/64 and arm/64
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

I don't build allyesconfigs any more (final? linking takes too long).
It builds successfully for arm64 allmodconfig, arm allmodconfig,
i386 allmodconfig, and x86_64 allmodconfig.

And the source files that use VERIFY_OCTAL_PERMISSIONS() all build successfully
(which means that they possibly include <linux/sysfs.h> indirectly, i.e.,
by luck). There aren't many of them, so I checked:

arch/arc/kernel/perf_event.c:	arc_pmu->attr[j].attr.attr.mode = VERIFY_OCTAL_PERMISSIONS(0444);
INDIRECT
drivers/edac/thunderx_edac.c:	.mode = VERIFY_OCTAL_PERMISSIONS(_mode),		    \
INDIRECT
drivers/media/platform/amphion/vpu_dbg.c:		    VERIFY_OCTAL_PERMISSIONS(0644),
INDIRECT
drivers/soc/aspeed/aspeed-uart-routing.c:	 .mode = VERIFY_OCTAL_PERMISSIONS(0644) },	\
INDIRECT
fs/xfs/xfs_error.c:		 .mode = VERIFY_OCTAL_PERMISSIONS(S_IWUSR | S_IRUGO) },	\
INDIRECT
include/linux/moduleparam.h:	    VERIFY_OCTAL_PERMISSIONS(perm), level, flags, { arg } }
INDIRECT

so all of them got lucky. :)

Acked-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
-- 
~Randy

Re: [PATCH 2/3] kernel.h: move VERIFY_OCTAL_PERMISSIONS() to sysfs.h

[Yury Norov]

On Sat, Nov 29, 2025 at 10:19:29PM -0800, Randy Dunlap wrote:
> 
> 
> On 11/29/25 12:24 PM, Andy Shevchenko wrote:
> > On Sat, Nov 29, 2025 at 02:53:01PM -0500, Yury Norov (NVIDIA) wrote:
> >> The macro is related to sysfs, but is defined in kernel.h. Move it to
> >> the proper header, and unload the generic kernel.h.
> > 
> > Tough guy :-)
> > I hope it builds well in your case.
> > 
> > FWIW,
> > https://lore.kernel.org/lkml/20220603172101.49950-1-andriy.shevchenko@linux.intel.com/
> > https://lore.kernel.org/lkml/20240212115500.2078463-1-max.kellermann@ionos.com/
> > https://lore.kernel.org/lkml/20240215093646.3265823-1-max.kellermann@ionos.com/
> > 
> > Assuming it builds in allmodconfig, allyesconfig on x86_32/64 and arm/64
> > Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> 
> I don't build allyesconfigs any more (final? linking takes too long).
> It builds successfully for arm64 allmodconfig, arm allmodconfig,
> i386 allmodconfig, and x86_64 allmodconfig.
> 
> And the source files that use VERIFY_OCTAL_PERMISSIONS() all build successfully
> (which means that they possibly include <linux/sysfs.h> indirectly, i.e.,
> by luck). There aren't many of them, so I checked:
> 
> arch/arc/kernel/perf_event.c:	arc_pmu->attr[j].attr.attr.mode = VERIFY_OCTAL_PERMISSIONS(0444);
> INDIRECT
> drivers/edac/thunderx_edac.c:	.mode = VERIFY_OCTAL_PERMISSIONS(_mode),		    \
> INDIRECT
> drivers/media/platform/amphion/vpu_dbg.c:		    VERIFY_OCTAL_PERMISSIONS(0644),
> INDIRECT
> drivers/soc/aspeed/aspeed-uart-routing.c:	 .mode = VERIFY_OCTAL_PERMISSIONS(0644) },	\
> INDIRECT
> fs/xfs/xfs_error.c:		 .mode = VERIFY_OCTAL_PERMISSIONS(S_IWUSR | S_IRUGO) },	\
> INDIRECT
> include/linux/moduleparam.h:	    VERIFY_OCTAL_PERMISSIONS(perm), level, flags, { arg } }
> INDIRECT
> 
> so all of them got lucky. :)
> 
> Acked-by: Randy Dunlap <rdunlap@infradead.org>
> Tested-by: Randy Dunlap <rdunlap@infradead.org>

Thanks, Randy.

This series was tested by 0-day and LKP. 0-day runs allyesconfig, as
far as I know. It only sends email in case of errors. LKP is OK, find
the report below.

All but XFS include it via linux/module.h -> linux/moduleparam.h path.
XFS has a linkage layer: xfs.h -> xfs_linux.h-> linux/module.h, so
it's pretty much the same.

I think, module.h inclusion path is OK for this macro and definitely
better than kernel.h. Notice, none of them, except for vgpu_dbg,
include kernel.h directly.

Thanks,
Yury

tree/branch: https://github.com/norov/linux stack_magic
branch HEAD: d8dffbf7bce40e2fbfe077f9c9f4a3471786666f  tracing: move tracing declarations from kernel.h to a dedicated header

elapsed time: 1669m

configs tested: 103
configs skipped: 2

The following configs have been built successfully.
More configs may be tested in the coming days.

tested configs:
alpha                   allnoconfig    gcc-15.1.0
alpha                     defconfig    gcc-15.1.0
arc                     allnoconfig    gcc-15.1.0
arc                       defconfig    gcc-15.1.0
arc         randconfig-001-20251128    gcc-8.5.0
arc         randconfig-002-20251128    gcc-15.1.0
arm                     allnoconfig    clang-22
arm           am200epdkit_defconfig    gcc-15.1.0
arm             aspeed_g5_defconfig    gcc-15.1.0
arm         randconfig-001-20251128    gcc-14.3.0
arm         randconfig-002-20251128    gcc-8.5.0
arm         randconfig-003-20251128    clang-22
arm         randconfig-004-20251128    clang-17
arm               s3c6400_defconfig    gcc-15.1.0
arm                 u8500_defconfig    gcc-15.1.0
arm64                   allnoconfig    gcc-15.1.0
arm64       randconfig-001-20251129    clang-22
arm64       randconfig-002-20251129    clang-22
arm64       randconfig-003-20251129    gcc-8.5.0
arm64       randconfig-004-20251129    clang-22
csky                    allnoconfig    gcc-15.1.0
csky        randconfig-001-20251129    gcc-15.1.0
csky        randconfig-002-20251129    gcc-15.1.0
hexagon                 allnoconfig    clang-22
hexagon     randconfig-001-20251129    clang-22
hexagon     randconfig-002-20251129    clang-22
i386                    allnoconfig    gcc-14
i386        randconfig-001-20251129    gcc-14
i386        randconfig-002-20251129    gcc-12
i386        randconfig-003-20251129    clang-20
i386        randconfig-004-20251129    gcc-14
i386        randconfig-005-20251129    clang-20
i386        randconfig-006-20251129    clang-20
i386        randconfig-007-20251129    gcc-14
i386        randconfig-011-20251129    clang-20
i386        randconfig-012-20251129    gcc-13
i386        randconfig-013-20251129    clang-20
i386        randconfig-014-20251129    clang-20
i386        randconfig-015-20251129    gcc-14
loongarch               allnoconfig    clang-22
loongarch                 defconfig    clang-19
loongarch   randconfig-001-20251129    gcc-15.1.0
loongarch   randconfig-002-20251129    gcc-14.3.0
m68k                    allnoconfig    gcc-15.1.0
m68k                      defconfig    gcc-15.1.0
microblaze              allnoconfig    gcc-15.1.0
microblaze                defconfig    gcc-15.1.0
mips                    allnoconfig    gcc-15.1.0
nios2                   allnoconfig    gcc-11.5.0
nios2                     defconfig    gcc-11.5.0
nios2       randconfig-001-20251129    gcc-11.5.0
nios2       randconfig-002-20251129    gcc-11.5.0
openrisc                allnoconfig    gcc-15.1.0
openrisc                  defconfig    gcc-15.1.0
parisc                  allnoconfig    gcc-15.1.0
parisc                    defconfig    gcc-15.1.0
parisc      generic-64bit_defconfig    gcc-15.1.0
parisc      randconfig-001-20251128    gcc-14.3.0
parisc      randconfig-002-20251128    gcc-15.1.0
parisc64                  defconfig    gcc-15.1.0
powerpc                 allnoconfig    gcc-15.1.0
powerpc            pcm030_defconfig    clang-22
powerpc     randconfig-001-20251128    gcc-11.5.0
powerpc     randconfig-002-20251128    clang-22
powerpc64   randconfig-001-20251128    clang-22
powerpc64   randconfig-002-20251128    gcc-8.5.0
riscv                   allnoconfig    gcc-15.1.0
riscv                     defconfig    clang-22
s390                    allnoconfig    clang-22
s390                      defconfig    clang-22
sh                      allnoconfig    gcc-15.1.0
sh                        defconfig    gcc-15.1.0
sparc                   allnoconfig    gcc-15.1.0
sparc                     defconfig    gcc-15.1.0
sparc       randconfig-001-20251129    gcc-8.5.0
sparc       randconfig-002-20251129    gcc-8.5.0
sparc64                   defconfig    clang-20
sparc64     randconfig-001-20251129    gcc-8.5.0
sparc64     randconfig-002-20251129    gcc-14.3.0
um                      allnoconfig    clang-22
um                        defconfig    clang-22
um                   i386_defconfig    gcc-14
um          randconfig-001-20251129    clang-22
um          randconfig-002-20251129    gcc-14
um                 x86_64_defconfig    clang-22
x86_64                  allnoconfig    clang-20
x86_64                    defconfig    gcc-14
x86_64      randconfig-011-20251129    gcc-14
x86_64      randconfig-012-20251129    gcc-14
x86_64      randconfig-013-20251129    gcc-14
x86_64      randconfig-014-20251129    clang-20
x86_64      randconfig-015-20251129    gcc-12
x86_64      randconfig-016-20251129    clang-20
x86_64      randconfig-071-20251129    gcc-14
x86_64      randconfig-072-20251129    clang-20
x86_64      randconfig-073-20251129    gcc-14
x86_64      randconfig-074-20251129    gcc-12
x86_64      randconfig-075-20251129    gcc-14
x86_64      randconfig-076-20251129    gcc-14
xtensa                  allnoconfig    gcc-15.1.0
xtensa      randconfig-001-20251129    gcc-10.5.0
xtensa      randconfig-002-20251129    gcc-14.3.0
xtensa          xip_kc705_defconfig    gcc-15.1.0

--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [PATCH 2/3] kernel.h: move VERIFY_OCTAL_PERMISSIONS() to sysfs.h

[Andy Shevchenko]

On Sun, Nov 30, 2025 at 12:42:35PM -0500, Yury Norov wrote:
> On Sat, Nov 29, 2025 at 10:19:29PM -0800, Randy Dunlap wrote:
> > 
> > 
> > On 11/29/25 12:24 PM, Andy Shevchenko wrote:
> > > On Sat, Nov 29, 2025 at 02:53:01PM -0500, Yury Norov (NVIDIA) wrote:
> > >> The macro is related to sysfs, but is defined in kernel.h. Move it to
> > >> the proper header, and unload the generic kernel.h.
> > > 
> > > Tough guy :-)
> > > I hope it builds well in your case.
> > > 
> > > FWIW,
> > > https://lore.kernel.org/lkml/20220603172101.49950-1-andriy.shevchenko@linux.intel.com/
> > > https://lore.kernel.org/lkml/20240212115500.2078463-1-max.kellermann@ionos.com/
> > > https://lore.kernel.org/lkml/20240215093646.3265823-1-max.kellermann@ionos.com/
> > > 
> > > Assuming it builds in allmodconfig, allyesconfig on x86_32/64 and arm/64
> > > Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > 
> > I don't build allyesconfigs any more (final? linking takes too long).
> > It builds successfully for arm64 allmodconfig, arm allmodconfig,
> > i386 allmodconfig, and x86_64 allmodconfig.
> > 
> > And the source files that use VERIFY_OCTAL_PERMISSIONS() all build successfully
> > (which means that they possibly include <linux/sysfs.h> indirectly, i.e.,
> > by luck). There aren't many of them, so I checked:
> > 
> > arch/arc/kernel/perf_event.c:	arc_pmu->attr[j].attr.attr.mode = VERIFY_OCTAL_PERMISSIONS(0444);
> > INDIRECT
> > drivers/edac/thunderx_edac.c:	.mode = VERIFY_OCTAL_PERMISSIONS(_mode),		    \
> > INDIRECT
> > drivers/media/platform/amphion/vpu_dbg.c:		    VERIFY_OCTAL_PERMISSIONS(0644),
> > INDIRECT
> > drivers/soc/aspeed/aspeed-uart-routing.c:	 .mode = VERIFY_OCTAL_PERMISSIONS(0644) },	\
> > INDIRECT
> > fs/xfs/xfs_error.c:		 .mode = VERIFY_OCTAL_PERMISSIONS(S_IWUSR | S_IRUGO) },	\
> > INDIRECT
> > include/linux/moduleparam.h:	    VERIFY_OCTAL_PERMISSIONS(perm), level, flags, { arg } }
> > INDIRECT
> > 
> > so all of them got lucky. :)
> > 
> > Acked-by: Randy Dunlap <rdunlap@infradead.org>
> > Tested-by: Randy Dunlap <rdunlap@infradead.org>
> 
> Thanks, Randy.
> 
> This series was tested by 0-day and LKP. 0-day runs allyesconfig,

AFAICS in the below no configuration had been tested against allYESconfig.
All of them are allNOconfig.

> as far as I know. It only sends email in case of errors. LKP is OK, find the
> report below.

> All but XFS include it via linux/module.h -> linux/moduleparam.h path.
> XFS has a linkage layer: xfs.h -> xfs_linux.h-> linux/module.h, so
> it's pretty much the same.
> 
> I think, module.h inclusion path is OK for this macro and definitely
> better than kernel.h. Notice, none of them, except for vgpu_dbg,
> include kernel.h directly.

Ideally those (especially and in the first place headers) should follow IWYU
principle and avoid indirect (non-guaranteed) inclusions.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 2/3] kernel.h: move VERIFY_OCTAL_PERMISSIONS() to sysfs.h

[Randy Dunlap]

On 11/30/25 11:38 AM, Andy Shevchenko wrote:
> On Sun, Nov 30, 2025 at 12:42:35PM -0500, Yury Norov wrote:

>> This series was tested by 0-day and LKP. 0-day runs allyesconfig,
> 
> AFAICS in the below no configuration had been tested against allYESconfig.
> All of them are allNOconfig.
> 
>> as far as I know. It only sends email in case of errors. LKP is OK, find the
>> report below.
> 
>> All but XFS include it via linux/module.h -> linux/moduleparam.h path.
>> XFS has a linkage layer: xfs.h -> xfs_linux.h-> linux/module.h, so
>> it's pretty much the same.
>>
>> I think, module.h inclusion path is OK for this macro and definitely
>> better than kernel.h. Notice, none of them, except for vgpu_dbg,
>> include kernel.h directly.
> 
> Ideally those (especially and in the first place headers) should follow IWYU
> principle and avoid indirect (non-guaranteed) inclusions.

Can you (or anyone) get IWYU (software) to work?
I tried it a few months ago but didn't have the correct magic
incantation for it.
(no specifics at the moment)

-- 
~Randy

Re: [PATCH 2/3] kernel.h: move VERIFY_OCTAL_PERMISSIONS() to sysfs.h

[Andy Shevchenko]

On Mon, Dec 01, 2025 at 11:51:24AM -0800, Randy Dunlap wrote:
> On 11/30/25 11:38 AM, Andy Shevchenko wrote:
> > On Sun, Nov 30, 2025 at 12:42:35PM -0500, Yury Norov wrote:
> 
> >> This series was tested by 0-day and LKP. 0-day runs allyesconfig,
> > 
> > AFAICS in the below no configuration had been tested against allYESconfig.
> > All of them are allNOconfig.
> > 
> >> as far as I know. It only sends email in case of errors. LKP is OK, find the
> >> report below.
> > 
> >> All but XFS include it via linux/module.h -> linux/moduleparam.h path.
> >> XFS has a linkage layer: xfs.h -> xfs_linux.h-> linux/module.h, so
> >> it's pretty much the same.
> >>
> >> I think, module.h inclusion path is OK for this macro and definitely
> >> better than kernel.h. Notice, none of them, except for vgpu_dbg,
> >> include kernel.h directly.
> > 
> > Ideally those (especially and in the first place headers) should follow IWYU
> > principle and avoid indirect (non-guaranteed) inclusions.
> 
> Can you (or anyone) get IWYU (software) to work?
> I tried it a few months ago but didn't have the correct magic
> incantation for it.
> (no specifics at the moment)

You should talk to Jonathan Cameron (Cc'ed), he was able to run it to some
extent. AFAIR the state of affairs is that it gives a lot of low-level headers
that we should not really go too deep to (at least for now). That means the
carefully crafted map of guarantees needs to be provided (e.g., if we include
bitmap.h, bitops.h and/or bits.h are guaranteed, so no need to be included).

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 2/3] kernel.h: move VERIFY_OCTAL_PERMISSIONS() to sysfs.h

[Yury Norov]

On Sat, Nov 29, 2025 at 10:24:48PM +0200, Andy Shevchenko wrote:
> On Sat, Nov 29, 2025 at 02:53:01PM -0500, Yury Norov (NVIDIA) wrote:
> > The macro is related to sysfs, but is defined in kernel.h. Move it to
> > the proper header, and unload the generic kernel.h.
> 
> Tough guy :-)
> I hope it builds well in your case.
> 
> FWIW,
> https://lore.kernel.org/lkml/20220603172101.49950-1-andriy.shevchenko@linux.intel.com/
> https://lore.kernel.org/lkml/20240212115500.2078463-1-max.kellermann@ionos.com/
> https://lore.kernel.org/lkml/20240215093646.3265823-1-max.kellermann@ionos.com/

Oh, OK. Surely I didn't want to undercut your or Max's work. Do you
know why it wasn't merged in 2022 and 2024?
 
> Assuming it builds in allmodconfig, allyesconfig on x86_32/64 and arm/64
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

It seemingly builds well. Thanks for review.

Re: [PATCH 2/3] kernel.h: move VERIFY_OCTAL_PERMISSIONS() to sysfs.h

[Andy Shevchenko]

On Sun, Nov 30, 2025 at 01:27:45PM -0500, Yury Norov wrote:
> On Sat, Nov 29, 2025 at 10:24:48PM +0200, Andy Shevchenko wrote:
> > On Sat, Nov 29, 2025 at 02:53:01PM -0500, Yury Norov (NVIDIA) wrote:
> > > The macro is related to sysfs, but is defined in kernel.h. Move it to
> > > the proper header, and unload the generic kernel.h.
> > 
> > Tough guy :-)
> > I hope it builds well in your case.
> > 
> > FWIW,
> > https://lore.kernel.org/lkml/20220603172101.49950-1-andriy.shevchenko@linux.intel.com/
> > https://lore.kernel.org/lkml/20240212115500.2078463-1-max.kellermann@ionos.com/
> > https://lore.kernel.org/lkml/20240215093646.3265823-1-max.kellermann@ionos.com/
> 
> Oh, OK. Surely I didn't want to undercut your or Max's work.

It's not about undercutting, I referred just for your information.

> Do you know why it wasn't merged in 2022 and 2024?

I have no idea why his (shorten) version of the series had been ignored.
Perhaps wrong / missing Cc? Also he went too far on splitting things, and IIRC
I mentioned that to him in one of the review rounds (but not sure).

So, I think you can take his work as Originally-by: and modify accordingly.

> > Assuming it builds in allmodconfig, allyesconfig on x86_32/64 and arm/64
> > Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> 
> It seemingly builds well. Thanks for review.

That said, I'm totally fine with your patch as mine at least didn't build
that time.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 2/3] kernel.h: move VERIFY_OCTAL_PERMISSIONS() to sysfs.h

[Petr Pavlu]

On 11/29/25 8:53 PM, Yury Norov (NVIDIA) wrote:
> The macro is related to sysfs, but is defined in kernel.h. Move it to
> the proper header, and unload the generic kernel.h.
> 
> Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
> ---
>  include/linux/kernel.h      | 12 ------------
>  include/linux/moduleparam.h |  2 +-
>  include/linux/sysfs.h       | 13 +++++++++++++
>  3 files changed, 14 insertions(+), 13 deletions(-)
> 
> [...]
> diff --git a/include/linux/moduleparam.h b/include/linux/moduleparam.h
> index 6907aedc4f74..4e390a84a8bc 100644
> --- a/include/linux/moduleparam.h
> +++ b/include/linux/moduleparam.h
> @@ -4,7 +4,7 @@
>  /* (C) Copyright 2001, 2002 Rusty Russell IBM Corporation */
>  #include <linux/init.h>
>  #include <linux/stringify.h>
> -#include <linux/kernel.h>
> +#include <linux/sysfs.h>

If you are removing the kernel.h include from
include/linux/moduleparam.h, I think it would be good to update the file
to ensure that all necessary includes are now listed directly.

The following items are present in moduleparam.h:

* __UNIQUE_ID(), __used(), __section(), __aligned(), __always_unused()
  -> linux/compiler.h,
* THIS_MODULE -> linux/init.h,
* __stringify() -> linux/stringify.h,
* u8, s8, u16, ... -> linux/types.h,
* static_assert() -> linux/build_bug.h,
* VERIFY_OCTAL_PERMISSIONS() -> linux/sysfs.h,
* ARRAY_SIZE() -> linux/array_size.h.

I suggest then updating the includes in include/linux/moduleparam.h to:

#include <linux/array_size.h>
#include <linux/build_bug.h>
#include <linux/compiler.h>
#include <linux/init.h>
#include <linux/stringify.h>
#include <linux/sysfs.h>
#include <linux/types.h>

-- 
Thanks,
Petr

Re: [PATCH 2/3] kernel.h: move VERIFY_OCTAL_PERMISSIONS() to sysfs.h

[Andy Shevchenko]

On Mon, Dec 01, 2025 at 08:01:23PM +0100, Petr Pavlu wrote:
> On 11/29/25 8:53 PM, Yury Norov (NVIDIA) wrote:

...

> > -#include <linux/kernel.h>
> > +#include <linux/sysfs.h>
> 
> If you are removing the kernel.h include from
> include/linux/moduleparam.h, I think it would be good to update the file
> to ensure that all necessary includes are now listed directly.
> 
> The following items are present in moduleparam.h:
> 
> * __UNIQUE_ID(), __used(), __section(), __aligned(), __always_unused()
>   -> linux/compiler.h,
> * THIS_MODULE -> linux/init.h,
> * __stringify() -> linux/stringify.h,
> * u8, s8, u16, ... -> linux/types.h,
> * static_assert() -> linux/build_bug.h,
> * VERIFY_OCTAL_PERMISSIONS() -> linux/sysfs.h,
> * ARRAY_SIZE() -> linux/array_size.h.
> 
> I suggest then updating the includes in include/linux/moduleparam.h to:
> 
> #include <linux/array_size.h>
> #include <linux/build_bug.h>
> #include <linux/compiler.h>
> #include <linux/init.h>
> #include <linux/stringify.h>
> #include <linux/sysfs.h>
> #include <linux/types.h>

Good point. And since we are not adding some top-level ones, this shouldn't
be worse (in terms of potential cyclic dependencies).

-- 
With Best Regards,
Andy Shevchenko

[PATCH 3/3] tracing: move tracing declarations from kernel.h to a dedicated header

[Yury Norov (NVIDIA)]

Tracing is a half of the kernel.h in terms of LOCs, although it's a
self-consistent part. Move it to a separate header.

This is a pure move, except for removing a few 'extern's.

Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
---
 MAINTAINERS             |   1 +
 include/linux/kernel.h  | 195 +-------------------------------------
 include/linux/tracing.h | 203 ++++++++++++++++++++++++++++++++++++++++
 3 files changed, 205 insertions(+), 194 deletions(-)
 create mode 100644 include/linux/tracing.h

diff --git a/MAINTAINERS b/MAINTAINERS
index be6a4217caa5..706bbb5da263 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -26071,6 +26071,7 @@ T:	git git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace.git
 F:	Documentation/trace/*
 F:	fs/tracefs/
 F:	include/linux/trace*.h
+F:	include/linux/tracing.h
 F:	include/trace/
 F:	kernel/trace/
 F:	kernel/tracepoint.c
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 5b879bfea948..265c0d31f369 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -27,6 +27,7 @@
 #include <linux/math.h>
 #include <linux/minmax.h>
 #include <linux/typecheck.h>
+#include <linux/tracing.h>
 #include <linux/panic.h>
 #include <linux/printk.h>
 #include <linux/build_bug.h>
@@ -190,200 +191,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, strlen(str));		\
-})
-extern int __trace_bputs(unsigned long ip, const char *str);
-extern int __trace_puts(unsigned long ip, const char *str, int size);
-
-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/tracing.h b/include/linux/tracing.h
new file mode 100644
index 000000000000..1989e6328c59
--- /dev/null
+++ b/include/linux/tracing.h
@@ -0,0 +1,203 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _LINUX_TRACING_H
+#define _LINUX_TRACING_H
+
+#include <linux/compiler_attributes.h>
+#include <linux/instruction_pointer.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);
+
+void tracing_start(void);
+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)
+
+__printf(2, 3)
+int __trace_bprintk(unsigned long ip, const char *fmt, ...);
+
+__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, strlen(str));		\
+})
+int __trace_bputs(unsigned long ip, const char *str);
+int __trace_puts(unsigned long ip, const char *str, int size);
+
+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)
+
+__printf(2, 0) int
+__ftrace_vbprintk(unsigned long ip, const char *fmt, va_list ap);
+
+__printf(2, 0) int
+__ftrace_vprintk(unsigned long ip, const char *fmt, va_list ap);
+
+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

Re: [PATCH 3/3] tracing: move tracing declarations from kernel.h to a dedicated header

[Andy Shevchenko]

On Sat, Nov 29, 2025 at 02:53:02PM -0500, Yury Norov (NVIDIA) wrote:
> Tracing is a half of the kernel.h in terms of LOCs, although it's a
> self-consistent part. Move it to a separate header.
> 
> This is a pure move, except for removing a few 'extern's.

Yeah, I also have something similar (but half-baked) locally, the Q I wanted to
ask is why a separate header? We have already some of tracing headers. Doesn't
suit well?

...

> --- a/include/linux/kernel.h
> +++ b/include/linux/kernel.h
> @@ -27,6 +27,7 @@
>  #include <linux/math.h>
>  #include <linux/minmax.h>
>  #include <linux/typecheck.h>

> +#include <linux/tracing.h>

There is better place for t*.h, i.e. after static_call_types.h.

Btw, have you tried to sort alphabetically the bulk in the kernel.h after
your series. Does it still build? (Just wondering about state of affairs
with the possible cyclic dependencies.)

>  #include <linux/panic.h>
>  #include <linux/printk.h>
>  #include <linux/build_bug.h>

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 3/3] tracing: move tracing declarations from kernel.h to a dedicated header

[Yury Norov]

On Sat, Nov 29, 2025 at 10:30:23PM +0200, Andy Shevchenko wrote:
> On Sat, Nov 29, 2025 at 02:53:02PM -0500, Yury Norov (NVIDIA) wrote:
> > Tracing is a half of the kernel.h in terms of LOCs, although it's a
> > self-consistent part. Move it to a separate header.
> > 
> > This is a pure move, except for removing a few 'extern's.
> 
> Yeah, I also have something similar (but half-baked) locally, the Q I wanted to
> ask is why a separate header? We have already some of tracing headers. Doesn't
> suit well?

Just as said in the commit message - this part is more or less
self-consistent and debugging-oriented. If someone needs to just
throw trace_printk() in their driver, they will not have to pull
all the heavy tracing machinery.

> ...
> 
> > --- a/include/linux/kernel.h
> > +++ b/include/linux/kernel.h
> > @@ -27,6 +27,7 @@
> >  #include <linux/math.h>
> >  #include <linux/minmax.h>
> >  #include <linux/typecheck.h>
> 
> > +#include <linux/tracing.h>
> 
> There is better place for t*.h, i.e. after static_call_types.h.

They are poorly sorted for seemingly no good reason. I found the first
t*.h and just put this header next to it. Don't think that placing it
next to static_call_types.h is any better or worse.
 
> Btw, have you tried to sort alphabetically the bulk in the kernel.h after
> your series. Does it still build? (Just wondering about state of affairs
> with the possible cyclic dependencies.)

I didn't try. Sorting #include's is not the purpose of the series.

Thanks,
Yury

Re: [PATCH 3/3] tracing: move tracing declarations from kernel.h to a dedicated header

[Andy Shevchenko]

On Sun, Nov 30, 2025 at 01:16:19PM -0500, Yury Norov wrote:
> On Sat, Nov 29, 2025 at 10:30:23PM +0200, Andy Shevchenko wrote:
> > On Sat, Nov 29, 2025 at 02:53:02PM -0500, Yury Norov (NVIDIA) wrote:
> > > Tracing is a half of the kernel.h in terms of LOCs, although it's a
> > > self-consistent part. Move it to a separate header.
> > > 
> > > This is a pure move, except for removing a few 'extern's.
> > 
> > Yeah, I also have something similar (but half-baked) locally, the Q I wanted to
> > ask is why a separate header? We have already some of tracing headers. Doesn't
> > suit well?
> 
> Just as said in the commit message - this part is more or less
> self-consistent and debugging-oriented. If someone needs to just
> throw trace_printk() in their driver, they will not have to pull
> all the heavy tracing machinery.

Please, add a summary of this to it. It will be much clearer and based on it
I agree with your judgement.

...

> > > --- a/include/linux/kernel.h
> > > +++ b/include/linux/kernel.h
> > > @@ -27,6 +27,7 @@
> > >  #include <linux/math.h>
> > >  #include <linux/minmax.h>
> > >  #include <linux/typecheck.h>
> > 
> > > +#include <linux/tracing.h>
> > 
> > There is better place for t*.h, i.e. after static_call_types.h.
> 
> They are poorly sorted for seemingly no good reason. I found the first
> t*.h and just put this header next to it. Don't think that placing it
> next to static_call_types.h is any better or worse.

It's better, because the (sparsed) chain of the sorted one is longer.

> > Btw, have you tried to sort alphabetically the bulk in the kernel.h after
> > your series. Does it still build? (Just wondering about state of affairs
> > with the possible cyclic dependencies.)
> 
> I didn't try. Sorting #include's is not the purpose of the series.

I know, I'm _just wondering_.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 3/3] tracing: move tracing declarations from kernel.h to a dedicated header

[Steven Rostedt]

On Sun, 30 Nov 2025 21:44:46 +0200
Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:

> On Sun, Nov 30, 2025 at 01:16:19PM -0500, Yury Norov wrote:
> > On Sat, Nov 29, 2025 at 10:30:23PM +0200, Andy Shevchenko wrote:  
> > > On Sat, Nov 29, 2025 at 02:53:02PM -0500, Yury Norov (NVIDIA) wrote:  
> > > > Tracing is a half of the kernel.h in terms of LOCs, although it's a
> > > > self-consistent part. Move it to a separate header.
> > > > 
> > > > This is a pure move, except for removing a few 'extern's.  
> > > 
> > > Yeah, I also have something similar (but half-baked) locally, the Q I wanted to
> > > ask is why a separate header? We have already some of tracing headers. Doesn't
> > > suit well?  
> > 
> > Just as said in the commit message - this part is more or less
> > self-consistent and debugging-oriented. If someone needs to just
> > throw trace_printk() in their driver, they will not have to pull
> > all the heavy tracing machinery.  
> 
> Please, add a summary of this to it. It will be much clearer and based on it
> I agree with your judgement.

Agreed. Please update the change log stating that the tracing code in
kernel.h is only used for quick debugging purposes and is not used for
the normal tracing utilities.

-- Steve

Re: [PATCH 3/3] tracing: move tracing declarations from kernel.h to a dedicated header

[david laight]

On Sun, 30 Nov 2025 21:44:46 +0200
Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:

> On Sun, Nov 30, 2025 at 01:16:19PM -0500, Yury Norov wrote:
> > On Sat, Nov 29, 2025 at 10:30:23PM +0200, Andy Shevchenko wrote:  
> > > On Sat, Nov 29, 2025 at 02:53:02PM -0500, Yury Norov (NVIDIA) wrote:  
> > > > Tracing is a half of the kernel.h in terms of LOCs, although it's a
> > > > self-consistent part. Move it to a separate header.
> > > > 
> > > > This is a pure move, except for removing a few 'extern's.  
> > > 
> > > Yeah, I also have something similar (but half-baked) locally, the Q I wanted to
> > > ask is why a separate header? We have already some of tracing headers. Doesn't
> > > suit well?  
> > 
> > Just as said in the commit message - this part is more or less
> > self-consistent and debugging-oriented. If someone needs to just
> > throw trace_printk() in their driver, they will not have to pull
> > all the heavy tracing machinery.  
> 
> Please, add a summary of this to it. It will be much clearer and based on it
> I agree with your judgement.

It is worth checking whether the files get included anyway, and whether it
really makes that much difference.

Fiddling with kernel.h and extracting small 'leaf' headers from it is also
unlikely to make a big difference.

Try adding a syntax error to (say) sys/ioctl.h and see where it is included
from the first time - I suspect you'll be surprised.
Working on that include list might be more fruitful (in reducing build times).

	David

Re: [PATCH 3/3] tracing: move tracing declarations from kernel.h to a dedicated header

[Andy Shevchenko]

On Sun, Nov 30, 2025 at 11:09:25PM +0000, david laight wrote:
> On Sun, 30 Nov 2025 21:44:46 +0200
> Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:

...

> It is worth checking whether the files get included anyway, and whether it
> really makes that much difference.
> 
> Fiddling with kernel.h and extracting small 'leaf' headers from it is also
> unlikely to make a big difference.

It makes a big difference for the kernel.h and its (ab)users.
Especially when we have cyclic dependencies and "include everything"
cases due to other _headers_ including kernel.h.

> Try adding a syntax error to (say) sys/ioctl.h and see where it is included
> from the first time - I suspect you'll be surprised.
> Working on that include list might be more fruitful (in reducing build times).

kernel.h elimination (in the form it exists right now) is very fruitful.
However, you may help with the (say) ioctl.h or whatever you consider
really fruitful, we all will thank you (no jokes).

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 3/3] tracing: move tracing declarations from kernel.h to a dedicated header

[david laight]

On Mon, 1 Dec 2025 04:50:42 +0200
Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:

> On Sun, Nov 30, 2025 at 11:09:25PM +0000, david laight wrote:
> > On Sun, 30 Nov 2025 21:44:46 +0200
> > Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:  
> 
> ...
 
> kernel.h elimination (in the form it exists right now) is very fruitful.
> However, you may help with the (say) ioctl.h or whatever you consider
> really fruitful, we all will thank you (no jokes).
> 

This is the first #include path for ioctl.h

In file included from ../include/asm-generic/ioctl.h:5,
                 from ./arch/x86/include/generated/uapi/asm/ioctl.h:1,
                 from ../include/uapi/linux/ioctl.h:5,
                 from ../include/uapi/linux/random.h:12,
                 from ../include/linux/random.h:10,
                 from ../include/linux/nodemask.h:94,
                 from ../include/linux/numa.h:6,
                 from ../include/linux/cpumask.h:17,
                 from ../arch/x86/include/asm/paravirt.h:21,
                 from ../arch/x86/include/asm/irqflags.h:102,
                 from ../include/linux/irqflags.h:18,
                 from ../include/linux/spinlock.h:59,
                 from ../include/linux/swait.h:7,
                 from ../include/linux/completion.h:12,
                 from ../include/linux/crypto.h:15,
                 from ../arch/x86/kernel/asm-offsets.c:9:

Get past that and sched.h => processor.h => cpuid/api.h also
gets you to paravirt.h.
I suspect a lot of headers get pulled in like that.

	David
 

Re: [PATCH 3/3] tracing: move tracing declarations from kernel.h to a dedicated header

[Andy Shevchenko]

On Mon, Dec 01, 2025 at 10:16:58AM +0000, david laight wrote:
> On Mon, 1 Dec 2025 04:50:42 +0200
> Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> > On Sun, Nov 30, 2025 at 11:09:25PM +0000, david laight wrote:
> > > On Sun, 30 Nov 2025 21:44:46 +0200
> > > Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:  

...

> > kernel.h elimination (in the form it exists right now) is very fruitful.
> > However, you may help with the (say) ioctl.h or whatever you consider
> > really fruitful, we all will thank you (no jokes).
> > 
> 
> This is the first #include path for ioctl.h
> 
> In file included from ../include/asm-generic/ioctl.h:5,
>                  from ./arch/x86/include/generated/uapi/asm/ioctl.h:1,
>                  from ../include/uapi/linux/ioctl.h:5,
>                  from ../include/uapi/linux/random.h:12,
>                  from ../include/linux/random.h:10,
>                  from ../include/linux/nodemask.h:94,
>                  from ../include/linux/numa.h:6,
>                  from ../include/linux/cpumask.h:17,
>                  from ../arch/x86/include/asm/paravirt.h:21,
>                  from ../arch/x86/include/asm/irqflags.h:102,
>                  from ../include/linux/irqflags.h:18,
>                  from ../include/linux/spinlock.h:59,
>                  from ../include/linux/swait.h:7,
>                  from ../include/linux/completion.h:12,
>                  from ../include/linux/crypto.h:15,
>                  from ../arch/x86/kernel/asm-offsets.c:9:
> 
> Get past that and sched.h => processor.h => cpuid/api.h also
> gets you to paravirt.h.
> I suspect a lot of headers get pulled in like that.

And several headers like ioctl.h that is "pull half of everything".
device.h, for example.

So, you can start untangling them piece by piece.
Not sure how [1] is actual right now, but I believe plenty of those
can still be used.

[1]: https://lwn.net/ml/linux-kernel/YdIfz+LMewetSaEB@gmail.com/

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 3/3] tracing: move tracing declarations from kernel.h to a dedicated header

[Steven Rostedt]

On Sat, 29 Nov 2025 14:53:02 -0500
"Yury Norov (NVIDIA)" <yury.norov@gmail.com> wrote:

> --- a/include/linux/kernel.h
> +++ b/include/linux/kernel.h
> @@ -27,6 +27,7 @@
>  #include <linux/math.h>
>  #include <linux/minmax.h>
>  #include <linux/typecheck.h>
> +#include <linux/tracing.h>
>  #include <linux/panic.h>
>  #include <linux/printk.h>
>  #include <linux/build_bug.h>

I'm fine with this as long as it's available as much as printk is.

Acked-by: Steven Rostedt <rostedt@goodmis.org>

-- Steve