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.0On 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
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
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
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.
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
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
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
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
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
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
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
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
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
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
© 2016 - 2025 Red Hat, Inc.