linux-kernel - Re: [PATCH 2/3] kernel.h: move VERIFY_OCTAL

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aSydSI-h3KZiYBn6@smile.fi.intel.com>
Date: Sun, 30 Nov 2025 21:38:48 +0200
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: Yury Norov <yury.norov@...il.com>
Cc: Randy Dunlap <rdunlap@...radead.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Masami Hiramatsu <mhiramat@...nel.org>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	Ingo Molnar <mingo@...nel.org>,
	Jani Nikula <jani.nikula@...ux.intel.com>,
	Joonas Lahtinen <joonas.lahtinen@...ux.intel.com>,
	Rodrigo Vivi <rodrigo.vivi@...el.com>,
	Tvrtko Ursulin <tursulin@...ulin.net>,
	Petr Pavlu <petr.pavlu@...e.com>,
	Daniel Gomez <da.gomez@...nel.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"Rafael J. Wysocki" <rafael@...nel.org>,
	Danilo Krummrich <dakr@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, intel-gfx@...ts.freedesktop.org,
	dri-devel@...ts.freedesktop.org, linux-modules@...r.kernel.org,
	linux-trace-kernel@...r.kernel.org
Subject: Re: [PATCH 2/3] kernel.h: move VERIFY_OCTAL_PERMISSIONS() to sysfs.h

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@...ux.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@...radead.org>
> > Tested-by: Randy Dunlap <rdunlap@...radead.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