* Re: [PATCH 3/3] tracing: move tracing declarations from kernel.h to a dedicated header
From: Andy Shevchenko @ 2025-11-30 19:44 UTC (permalink / raw)
To: Yury Norov
Cc: Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers, Randy Dunlap,
Ingo Molnar, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, Petr Pavlu, Daniel Gomez, Greg Kroah-Hartman,
Rafael J. Wysocki, Danilo Krummrich, Andrew Morton, linux-kernel,
intel-gfx, dri-devel, linux-modules, linux-trace-kernel
In-Reply-To: <aSyJ83v7EEAPHXeU@yury>
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
^ permalink raw reply
* Re: [PATCH 2/3] kernel.h: move VERIFY_OCTAL_PERMISSIONS() to sysfs.h
From: Andy Shevchenko @ 2025-11-30 19:42 UTC (permalink / raw)
To: Yury Norov
Cc: Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers, Randy Dunlap,
Ingo Molnar, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, Petr Pavlu, Daniel Gomez, Greg Kroah-Hartman,
Rafael J. Wysocki, Danilo Krummrich, Andrew Morton, linux-kernel,
intel-gfx, dri-devel, linux-modules, linux-trace-kernel
In-Reply-To: <aSyMobJnY4qKmsdk@yury>
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
^ permalink raw reply
* Re: [PATCH 2/3] kernel.h: move VERIFY_OCTAL_PERMISSIONS() to sysfs.h
From: Andy Shevchenko @ 2025-11-30 19:38 UTC (permalink / raw)
To: Yury Norov
Cc: Randy Dunlap, Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Ingo Molnar, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, Petr Pavlu, Daniel Gomez, Greg Kroah-Hartman,
Rafael J. Wysocki, Danilo Krummrich, Andrew Morton, linux-kernel,
intel-gfx, dri-devel, linux-modules, linux-trace-kernel
In-Reply-To: <aSyCC7TQoGgTn2rT@yury>
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
^ permalink raw reply
* Re: [PATCH 2/3] kernel.h: move VERIFY_OCTAL_PERMISSIONS() to sysfs.h
From: Andy Shevchenko @ 2025-11-30 19:35 UTC (permalink / raw)
To: Yury Norov
Cc: Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers, Randy Dunlap,
Ingo Molnar, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, Petr Pavlu, Daniel Gomez, Greg Kroah-Hartman,
Rafael J. Wysocki, Danilo Krummrich, Andrew Morton, linux-kernel,
intel-gfx, dri-devel, linux-modules, linux-trace-kernel
In-Reply-To: <aSyFNSqWv_A7JNpI@yury>
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
^ permalink raw reply
* Re: [PATCH 1/4] lib/crypto: Add ML-DSA verification support
From: Eric Biggers @ 2025-11-30 19:06 UTC (permalink / raw)
To: Becker, Hanno
Cc: Jason A. Donenfeld, linux-crypto@vger.kernel.org, David Howells,
Herbert Xu, Luis Chamberlain, Petr Pavlu, Daniel Gomez,
Sami Tolvanen, Ard Biesheuvel, Stephan Mueller, Lukas Wunner,
Ignat Korchagin, keyrings@vger.kernel.org,
linux-modules@vger.kernel.org, linux-kernel@vger.kernel.org,
matthias@kannwischer.eu
In-Reply-To: <1CB2640E-B918-4C90-933D-61D5B1954E6C@amazon.co.uk>
On Sun, Nov 30, 2025 at 07:15:22AM +0000, Becker, Hanno wrote:
> > - Vector registers (e.g. AVX) can be used in the kernel only in some
> > contexts, and only when they are explicitly saved and restored. So
> > we have to do our own integration of any code that uses them anyway.
> > There is also more overhead to each vector-optimized function than
> > there is in userspace, so very fine-grained optimization (e.g. as is
> > used in the Dilithium reference code) doesn't work too well.
>
> That's very useful, can you say more? Would one want some sort of
> configurable preamble/postamble in the top-level API which takes care of
> the necessary save/restore logic?
>
> What is the per-function overhead?
It varies by architecture, but usually it looks something like:
if (irq_fpu_usable()) {
kernel_fpu_begin();
avx_function();
kernel_fpu_end();
} else {
generic_function();
}
The overhead varies significantly by CPU, kernel config options, and
whether it's the first use since the current task last entered the
kernel. But it can be up to a few hundred cycles.
> > Note that the kernel already has optimized Keccak code. That already
> > covers the most performance-critical part of ML-DSA.
>
> No, this would need _batched_ Keccak. An ML-DSA implementation using
> only 1x-Keccak will never have competitive performance. See
> https://github.com/pq-code-package/mldsa-native/pull/754 for the
> performance loss from using unbatched Keccak only, on a variety of
> platforms; it's >2x for some.
>
> In turn, if you want to integrate batched Keccak -- but perhaps only on
> some platforms? -- you need to rewrite your entire code to make use of
> it. That's not a simple change, and part of what I mean when I say that
> the challenges are just deferred. Note that the official reference and
> AVX2 implementations duck this problem by duplicating the code and
> adjusting it, rather than looking for a common structure that could host
> both 'plain' and batched Keccak. I assume the amount of code duplication
> this brings would be unacceptable.
At least in my code, only the matrix expansion code would need to change
to take advantage of interleaved Keccak. The fact that other
implementations apparently are having trouble with this actually
suggests to me that perhaps they're not good implementations to use.
Anyway, no one has said they want this particular optimization in the
kernel anyway. And hopefully the future is native Keccak support
anyway; s390 already has it, and (at least) RISC-V is working on it.
- Eric
^ permalink raw reply
* Re: [PATCH 2/3] kernel.h: move VERIFY_OCTAL_PERMISSIONS() to sysfs.h
From: Yury Norov @ 2025-11-30 18:27 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers, Randy Dunlap,
Ingo Molnar, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, Petr Pavlu, Daniel Gomez, Greg Kroah-Hartman,
Rafael J. Wysocki, Danilo Krummrich, Andrew Morton, linux-kernel,
intel-gfx, dri-devel, linux-modules, linux-trace-kernel
In-Reply-To: <aStWkK6exUj9YEC1@smile.fi.intel.com>
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.
^ permalink raw reply
* Re: [PATCH 3/3] tracing: move tracing declarations from kernel.h to a dedicated header
From: Yury Norov @ 2025-11-30 18:16 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers, Randy Dunlap,
Ingo Molnar, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, Petr Pavlu, Daniel Gomez, Greg Kroah-Hartman,
Rafael J. Wysocki, Danilo Krummrich, Andrew Morton, linux-kernel,
intel-gfx, dri-devel, linux-modules, linux-trace-kernel
In-Reply-To: <aStX3242e3mo5H05@smile.fi.intel.com>
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
^ permalink raw reply
* Re: [PATCH 2/3] kernel.h: move VERIFY_OCTAL_PERMISSIONS() to sysfs.h
From: Yury Norov @ 2025-11-30 17:56 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers, Randy Dunlap,
Ingo Molnar, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, Petr Pavlu, Daniel Gomez, Greg Kroah-Hartman,
Rafael J. Wysocki, Danilo Krummrich, Andrew Morton, linux-kernel,
intel-gfx, dri-devel, linux-modules, linux-trace-kernel
In-Reply-To: <aStZKktOEWliXWT1@smile.fi.intel.com>
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
^ permalink raw reply related
* Re: [PATCH 2/3] kernel.h: move VERIFY_OCTAL_PERMISSIONS() to sysfs.h
From: Yury Norov @ 2025-11-30 17:42 UTC (permalink / raw)
To: Randy Dunlap
Cc: Andy Shevchenko, Steven Rostedt, Masami Hiramatsu,
Mathieu Desnoyers, Ingo Molnar, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Petr Pavlu, Daniel Gomez,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Andrew Morton, linux-kernel, intel-gfx, dri-devel, linux-modules,
linux-trace-kernel
In-Reply-To: <e0d34a20-7547-4788-8449-95fcd5588434@infradead.org>
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
^ permalink raw reply
* Re: [PATCH 1/4] lib/crypto: Add ML-DSA verification support
From: Becker, Hanno @ 2025-11-30 7:15 UTC (permalink / raw)
To: Jason A. Donenfeld, Eric Biggers
Cc: linux-crypto@vger.kernel.org, David Howells, Herbert Xu,
Luis Chamberlain, Petr Pavlu, Daniel Gomez, Sami Tolvanen,
Ard Biesheuvel, Stephan Mueller, Lukas Wunner, Ignat Korchagin,
keyrings@vger.kernel.org, linux-modules@vger.kernel.org,
linux-kernel@vger.kernel.org, matthias@kannwischer.eu
In-Reply-To: <aSuYUDdlZvZrXuUo@zx2c4.com>
Eric, Jason,
Thanks for the fast replies!
On 30/11/2025, 00:22, "Eric Biggers" <ebiggers@kernel.org
<mailto:ebiggers@kernel.org>> wrote:
> I think you may be underestimating how much the requirements of the
> kernel differ from userspace.
There is no doubt this is the case -- I am not a kernel guy -- so the
points you raise are very valuable.
Equally, you may be underestimating how much work it is to go from a
static verification-only code to something that the community will be
able to work with and extend in the future.
There's clearly opportunity to learn from each other here. If this patch
forms the 'mldsa-v1' for the kernel, it would be great to work together
to see if 'mldsa-v2' could come from mldsa-native.
> In none of them has the kernel community been successful with
> integrating a project wholesale, vs. just taking individual files.
I take that as a challenge. With AWS-LC we were also told that
mlkem-native would never be able to integrate wholesale -- and now it
is. It's a matter of goodwill and collaboration, and not a binary
yes/no -- if selected but minimal patches are needed, that's still
better than an entirely separate implementation, in my mind.
> - Kernel stack is 8 KB to 16 KB. ...
Yes, as mentioned we started working on a) bringing the memory usage
down, and b) making the use of heap/stack configurable.
> - Vector registers (e.g. AVX) can be used in the kernel only in some
> contexts, and only when they are explicitly saved and restored. So
> we have to do our own integration of any code that uses them anyway.
> There is also more overhead to each vector-optimized function than
> there is in userspace, so very fine-grained optimization (e.g. as is
> used in the Dilithium reference code) doesn't work too well.
That's very useful, can you say more? Would one want some sort of
configurable preamble/postamble in the top-level API which takes care of
the necessary save/restore logic?
What is the per-function overhead?
> - The vector intrinsics like <immintrin.h> can't be used in the
> kernel, as they depend on userspace headers. Thus, vector
> instructions can generally be used only in assembly code. I believe
> this problem is solvable with a combination of changes to GCC, clang,
> and the kernel, and I'd like to see that happen. But someone would
> need to do it.
The use of intrinsics is on the way out; the kernel isn't the only
project who can't use them.
Using assembly is also more suitable for our optimization and
verification approach in mlkem-native and mldsa-native: We superoptimize
some assembly using SLOTHY (https://github.com/slothy-optimizer/slothy/)
and then do 'post-hoc' verification of the final object code using
the HOL-Light/s2n-bignum (https://github.com/awslabs/s2n-bignum/)
infrastructure. In mlkem-native, all AArch64 assembly is developed and
verified in this way; in mldsa-native, we just completed the
verification of the AVX2 assembly for the base multiplication and the
NTT.
> Note that the kernel already has optimized Keccak code. That already
> covers the most performance-critical part of ML-DSA.
No, this would need _batched_ Keccak. An ML-DSA implementation using
only 1x-Keccak will never have competitive performance. See
https://github.com/pq-code-package/mldsa-native/pull/754 for the
performance loss from using unbatched Keccak only, on a variety of
platforms; it's >2x for some.
In turn, if you want to integrate batched Keccak -- but perhaps only on
some platforms? -- you need to rewrite your entire code to make use of
it. That's not a simple change, and part of what I mean when I say that
the challenges are just deferred. Note that the official reference and
AVX2 implementations duck this problem by duplicating the code and
adjusting it, rather than looking for a common structure that could host
both 'plain' and batched Keccak. I assume the amount of code duplication
this brings would be unacceptable.
On 30/11/2025, 01:06, "Jason A. Donenfeld" <Jason@zx2c4.com
<mailto:Jason@zx2c4.com>> wrote:
> I've added a bit of formally verified code to the kernel, and also
> ported some userspace crypto. In these cases, I wound up working with
> the authors of the code to make it more suitable to the requirements
> of kernel space -- even down to the formatting level. For example, the
> HACL* project needed some changes to KReMLin to make the variety of
> code fit into what the kernel expected. Andy Polyakov's code needed
> some internal functions exposed so that the kernel could do cpu
> capability based dispatch. And so on and so forth. There's always
> _something_.
100%. This is where we need support from someone in the kernel to even
know what needs doing. The caveat regarding SIMD usage Eric mentioned is
a good example. The CPU capability based dispatch, for example, was
something we flushed out when we did the AWS-LC integration: dispatch is
now configurable.
> If those are efforts you'd consider undertaking seriously, I'd be
> happy to assist or help guide the considerations.
We are taking mlkem/mldsa-native seriously and want to make them as
usable as possible. So, regardless of whether they'd ultimately end up
in the kernel, any support of the form "If you wanted to integrate this
in environment XXX [like the kernel], then you would need ..." is very
useful and we'd be grateful for it.
I don't expect this to be something we can rush through in a couple of
days, but something that's achieved with steady progress and
collaboration.
> Anyway, the bigger picture is that I'm very enthusiastic about getting
> formally verified crypto in the kernel, so these types of efforts are
> really very appreciated and welcomed. But it just takes a bit more
> work than usual.
Thank you, Jason, this is great to hear, and if you had time to work with
us, we'd really appreciate it.
Thanks,
Hanno & Matthias
^ permalink raw reply
* Re: [PATCH 2/3] kernel.h: move VERIFY_OCTAL_PERMISSIONS() to sysfs.h
From: Randy Dunlap @ 2025-11-30 6:19 UTC (permalink / raw)
To: Andy Shevchenko, Yury Norov (NVIDIA)
Cc: Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers, Ingo Molnar,
Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin,
Petr Pavlu, Daniel Gomez, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, Andrew Morton, linux-kernel, intel-gfx,
dri-devel, linux-modules, linux-trace-kernel
In-Reply-To: <aStWkK6exUj9YEC1@smile.fi.intel.com>
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
^ permalink raw reply
* Re: [PATCH 1/4] lib/crypto: Add ML-DSA verification support
From: Jason A. Donenfeld @ 2025-11-30 1:05 UTC (permalink / raw)
To: Eric Biggers
Cc: Becker, Hanno, linux-crypto@vger.kernel.org, David Howells,
Herbert Xu, Luis Chamberlain, Petr Pavlu, Daniel Gomez,
Sami Tolvanen, Ard Biesheuvel, Stephan Mueller, Lukas Wunner,
Ignat Korchagin, keyrings@vger.kernel.org,
linux-modules@vger.kernel.org, linux-kernel@vger.kernel.org,
matthias@kannwischer.eu
In-Reply-To: <20251130001911.GA12664@sol>
Hi Hanno,
Just to add to what Eric said...
On Sat, Nov 29, 2025 at 04:19:11PM -0800, Eric Biggers wrote:
> I think you may be underestimating how much the requirements of the
> kernel differ from userspace. Consider the following:
I've added a bit of formally verified code to the kernel, and also
ported some userspace crypto. In these cases, I wound up working with
the authors of the code to make it more suitable to the requirements of
kernel space -- even down to the formatting level. For example, the
HACL* project needed some changes to KReMLin to make the variety of code
fit into what the kernel expected. Andy Polyakov's code needed some
internal functions exposed so that the kernel could do cpu capability
based dispatch. And so on and so forth. There's always _something_.
I'd love to have a formally verified ML-DSA implementation (if we're to
have ML-DSA in the kernel anyhow, but it looks like that's happening).
But I almost guarantee that it's going to be some work to do. If those
are efforts you'd consider undertaking seriously, I'd be happy to assist
or help guide the considerations.
There's also another approach, which would be to formally verify Eric's
code, perhaps even using the same techniques as your own project, via
CBMC and such. In this case, the name of the game is usually to port the
kernel code to userspace. That generally winds up being a matter of
shimming out some headers and adding a few typedefs. There's a decent
amount of kernel test code or kernel tool code that does this, and lots
of shim headers already in the kernel that can be borrowed for this. But
usually, at least for crypto code, you can figure it out pretty quickly
by just trying to compile it and plugging the missing headers and types
as they come up.
The model checking might be more work with this latter approach, since
it's not already done like it is for the former, but the porting work is
probably much less arduous.
Anyway, the bigger picture is that I'm very enthusiastic about getting
formally verified crypto in the kernel, so these types of efforts are
really very appreciated and welcomed. But it just takes a bit more work
than usual.
Jason
^ permalink raw reply
* Re: [PATCH 1/4] lib/crypto: Add ML-DSA verification support
From: Eric Biggers @ 2025-11-30 0:19 UTC (permalink / raw)
To: Becker, Hanno
Cc: linux-crypto@vger.kernel.org, David Howells, Herbert Xu,
Luis Chamberlain, Petr Pavlu, Daniel Gomez, Sami Tolvanen,
Jason A . Donenfeld, Ard Biesheuvel, Stephan Mueller,
Lukas Wunner, Ignat Korchagin, keyrings@vger.kernel.org,
linux-modules@vger.kernel.org, linux-kernel@vger.kernel.org,
matthias@kannwischer.eu
In-Reply-To: <A7135B59-BAB5-451E-AD71-971F828054F0@amazon.co.uk>
On Sat, Nov 29, 2025 at 08:00:17PM +0000, Becker, Hanno wrote:
> It looks like this may be close, but for the record:
>
> The LF has a dedicated project for ML-DSA: https://github.com/pq-code-package/mldsa-native (part of the Post-Quantum Cryptography Alliance). It's derived from the reference implementation and adds automatically verified memory-safety + type-safety (= bounds-tracking) and a uniform backend interface for assembly optimizations; see the README for more details. It's licensed under Apache-2.0 OR MIT OR ISC.
>
> If you are sure that the kernel will never need sign/keygen support, or support for optimized assembly, the current ad-hoc patch may be fine. Otherwise, the challenges are likely just delayed, e.g. how to safely re-use parts of the current code for the timing-sensitive signing, or in contexts with other bounds assumptions, or how to integrate assembly optimizations. It may not seem so, but this is difficult to get right and where maintainability gets challenging.
>
> Verification here is a vehicle for maintainability: If you change any arithmetic code -- say you decide to do less modular reduction for performance -- you currently need very careful review that the bounds still check out in the worst case. In mldsa-native, this is re-checked automatically.
>
> mldsa-native is production-ready and in the process of being integrated into Amazon's AWS-LC crypto library; the sibling-project mlkem-native https://github.com/pq-code-package/mlkem-native already has been. mldsa-native is not yet a drop-in for the kernel, however. At the least, memory usage needs to be brought down and allocation be made flexible. We're working on it, and if the kernel community was interested in it, it'd give impetus to accelerate the work.
>
> This is just so you're aware. If mldsa-native is of interest, let us know -- it would be great to collaborate across the LF instead of duplicating efforts.
>
> Thanks,
> Hanno & Matthias (maintainers of mldsa-native)
(Side note: this patch series is up to v2. See
https://lore.kernel.org/linux-crypto/20251126203517.167040-1-ebiggers@kernel.org/
for the latest version as of this writing)
For context, this is at least the third different userspace project
that's been suggested to borrow ML-DSA code from, and not the first that
is a fork of the Dilithium reference code.
ML-DSA is also just one of dozens of algorithms the kernel supports. In
none of them has the kernel community been successful with integrating a
project wholesale, vs. just taking individual files.
So while mldsa-native looks like a great project, for the task in
question (adding basic ML-DSA verification support to the kernel) I'm
not sure it brings much new to the table. Of course, there's also no
corresponding kernel patch that proposes integrating mldsa-native into
the kernel, so it's a bit hypothetical at this point too. The
leancrypto proposal at least had a patch, so it was more concrete.
I think you may be underestimating how much the requirements of the
kernel differ from userspace. Consider the following:
- Kernel stack is 8 KB to 16 KB. mldsa-native's signature verification
code starts out by allocating ~100KB of memory on the stack. If that
code was built into the kernel, it would immediately write out of
bounds. Oops. So much for the formal verification of memory bounds.
- Vector registers (e.g. AVX) can be used in the kernel only in some
contexts, and only when they are explicitly saved and restored. So we
have to do our own integration of any code that uses them anyway.
There is also more overhead to each vector-optimized function than
there is in userspace, so very fine-grained optimization (e.g. as is
used in the Dilithium reference code) doesn't work too well.
- The vector intrinsics like <immintrin.h> can't be used in the kernel,
as they depend on userspace headers. Thus, vector instructions can
generally be used only in assembly code. I believe this problem is
solvable with a combination of changes to GCC, clang, and the kernel,
and I'd like to see that happen. But someone would need to do it.
Note that the kernel already has optimized Keccak code. That already
covers the most performance-critical part of ML-DSA. Besides that part,
I think we're fine with a portable implementation of ML-DSA. Consider
that that's always been what we've done for RSA, for example. Signature
verification performance just isn't that important in the kernel.
But even if we decide the kernel needs optimized ML-DSA ring operations
later, I don't think we get any free lunch. Userspace libraries aren't
directly usable in the kernel anyway, for the reasons I outlined above.
And we can always borrow things piecemeal, as we've always done.
Microbenchmark throughput also isn't everything: memory usage and code
size is very important too, often even more important. I haven't seen a
proposal that even comes close to my mldsa_verify() on those metrics.
We can't be 100% sure that the kernel will never need ML-DSA signing
support. But it's not needed now, it's something that architecturally
doesn't make much sense, and we'd prefer to avoid adding it. We
shouldn't overengineer things around requirements that don't exist.
Anyway, we also aren't stuck with one implementation forever. If
someone can actually do ML-DSA better, whether that's for
verification-only right now or for everything during a hypothetical
future addition of signing support, we can replace my lib/crypto/mldsa.c
with something else. *Usually* kernel code evolves incrementally, but
not always. Especially with the crypto algorithms, there are examples
where we've entirely swapped out an implementation.
- Eric
^ permalink raw reply
* Re: [PATCH 1/3] kernel.h: drop STACK_MAGIC macro
From: Randy Dunlap @ 2025-11-29 23:40 UTC (permalink / raw)
To: Andy Shevchenko, Yury Norov (NVIDIA)
Cc: Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers, Ingo Molnar,
Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin,
Petr Pavlu, Daniel Gomez, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, Andrew Morton, linux-kernel, intel-gfx,
dri-devel, linux-modules, linux-trace-kernel
In-Reply-To: <aStYXphpN84Nr8LZ@smile.fi.intel.com>
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
^ permalink raw reply
* Re: [PATCH 2/3] kernel.h: move VERIFY_OCTAL_PERMISSIONS() to sysfs.h
From: Andy Shevchenko @ 2025-11-29 20:35 UTC (permalink / raw)
To: Yury Norov (NVIDIA)
Cc: Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers, Randy Dunlap,
Ingo Molnar, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, Petr Pavlu, Daniel Gomez, Greg Kroah-Hartman,
Rafael J. Wysocki, Danilo Krummrich, Andrew Morton, linux-kernel,
intel-gfx, dri-devel, linux-modules, linux-trace-kernel
In-Reply-To: <aStYs-LDKbJe6zvW@smile.fi.intel.com>
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
^ permalink raw reply
* Re: [PATCH 2/3] kernel.h: move VERIFY_OCTAL_PERMISSIONS() to sysfs.h
From: Andy Shevchenko @ 2025-11-29 20:33 UTC (permalink / raw)
To: Yury Norov (NVIDIA)
Cc: Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers, Randy Dunlap,
Ingo Molnar, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, Petr Pavlu, Daniel Gomez, Greg Kroah-Hartman,
Rafael J. Wysocki, Danilo Krummrich, Andrew Morton, linux-kernel,
intel-gfx, dri-devel, linux-modules, linux-trace-kernel
In-Reply-To: <aStWkK6exUj9YEC1@smile.fi.intel.com>
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
^ permalink raw reply
* Re: [PATCH 1/3] kernel.h: drop STACK_MAGIC macro
From: Andy Shevchenko @ 2025-11-29 20:32 UTC (permalink / raw)
To: Yury Norov (NVIDIA)
Cc: Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers, Randy Dunlap,
Ingo Molnar, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, Petr Pavlu, Daniel Gomez, Greg Kroah-Hartman,
Rafael J. Wysocki, Danilo Krummrich, Andrew Morton, linux-kernel,
intel-gfx, dri-devel, linux-modules, linux-trace-kernel
In-Reply-To: <20251129195304.204082-2-yury.norov@gmail.com>
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
^ permalink raw reply
* Re: [PATCH 3/3] tracing: move tracing declarations from kernel.h to a dedicated header
From: Andy Shevchenko @ 2025-11-29 20:30 UTC (permalink / raw)
To: Yury Norov (NVIDIA)
Cc: Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers, Randy Dunlap,
Ingo Molnar, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, Petr Pavlu, Daniel Gomez, Greg Kroah-Hartman,
Rafael J. Wysocki, Danilo Krummrich, Andrew Morton, linux-kernel,
intel-gfx, dri-devel, linux-modules, linux-trace-kernel
In-Reply-To: <20251129195304.204082-4-yury.norov@gmail.com>
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
^ permalink raw reply
* Re: [PATCH 2/3] kernel.h: move VERIFY_OCTAL_PERMISSIONS() to sysfs.h
From: Andy Shevchenko @ 2025-11-29 20:24 UTC (permalink / raw)
To: Yury Norov (NVIDIA)
Cc: Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers, Randy Dunlap,
Ingo Molnar, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, Petr Pavlu, Daniel Gomez, Greg Kroah-Hartman,
Rafael J. Wysocki, Danilo Krummrich, Andrew Morton, linux-kernel,
intel-gfx, dri-devel, linux-modules, linux-trace-kernel
In-Reply-To: <20251129195304.204082-3-yury.norov@gmail.com>
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
^ permalink raw reply
* Re: [PATCH 1/4] lib/crypto: Add ML-DSA verification support
From: Becker, Hanno @ 2025-11-29 20:00 UTC (permalink / raw)
To: Eric Biggers
Cc: linux-crypto@vger.kernel.org, David Howells, Herbert Xu,
Luis Chamberlain, Petr Pavlu, Daniel Gomez, Sami Tolvanen,
Jason A . Donenfeld, Ard Biesheuvel, Stephan Mueller,
Lukas Wunner, Ignat Korchagin, keyrings@vger.kernel.org,
linux-modules@vger.kernel.org, linux-kernel@vger.kernel.org,
matthias@kannwischer.eu
In-Reply-To: <20251120003653.335863-2-ebiggers@kernel.org>
It looks like this may be close, but for the record:
The LF has a dedicated project for ML-DSA: https://github.com/pq-code-package/mldsa-native (part of the Post-Quantum Cryptography Alliance). It's derived from the reference implementation and adds automatically verified memory-safety + type-safety (= bounds-tracking) and a uniform backend interface for assembly optimizations; see the README for more details. It's licensed under Apache-2.0 OR MIT OR ISC.
If you are sure that the kernel will never need sign/keygen support, or support for optimized assembly, the current ad-hoc patch may be fine. Otherwise, the challenges are likely just delayed, e.g. how to safely re-use parts of the current code for the timing-sensitive signing, or in contexts with other bounds assumptions, or how to integrate assembly optimizations. It may not seem so, but this is difficult to get right and where maintainability gets challenging.
Verification here is a vehicle for maintainability: If you change any arithmetic code -- say you decide to do less modular reduction for performance -- you currently need very careful review that the bounds still check out in the worst case. In mldsa-native, this is re-checked automatically.
mldsa-native is production-ready and in the process of being integrated into Amazon's AWS-LC crypto library; the sibling-project mlkem-native https://github.com/pq-code-package/mlkem-native already has been. mldsa-native is not yet a drop-in for the kernel, however. At the least, memory usage needs to be brought down and allocation be made flexible. We're working on it, and if the kernel community was interested in it, it'd give impetus to accelerate the work.
This is just so you're aware. If mldsa-native is of interest, let us know -- it would be great to collaborate across the LF instead of duplicating efforts.
Thanks,
Hanno & Matthias (maintainers of mldsa-native)
^ permalink raw reply
* [PATCH 3/3] tracing: move tracing declarations from kernel.h to a dedicated header
From: Yury Norov (NVIDIA) @ 2025-11-29 19:53 UTC (permalink / raw)
To: Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Andy Shevchenko, Randy Dunlap, Ingo Molnar, Jani Nikula,
Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin, Petr Pavlu,
Daniel Gomez, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, Andrew Morton, linux-kernel, intel-gfx,
dri-devel, linux-modules, linux-trace-kernel
Cc: Yury Norov (NVIDIA)
In-Reply-To: <20251129195304.204082-1-yury.norov@gmail.com>
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
^ permalink raw reply related
* [PATCH 2/3] kernel.h: move VERIFY_OCTAL_PERMISSIONS() to sysfs.h
From: Yury Norov (NVIDIA) @ 2025-11-29 19:53 UTC (permalink / raw)
To: Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Andy Shevchenko, Randy Dunlap, Ingo Molnar, Jani Nikula,
Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin, Petr Pavlu,
Daniel Gomez, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, Andrew Morton, linux-kernel, intel-gfx,
dri-devel, linux-modules, linux-trace-kernel
Cc: Yury Norov (NVIDIA)
In-Reply-To: <20251129195304.204082-1-yury.norov@gmail.com>
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
^ permalink raw reply related
* [PATCH 1/3] kernel.h: drop STACK_MAGIC macro
From: Yury Norov (NVIDIA) @ 2025-11-29 19:53 UTC (permalink / raw)
To: Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Andy Shevchenko, Randy Dunlap, Ingo Molnar, Jani Nikula,
Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin, Petr Pavlu,
Daniel Gomez, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, Andrew Morton, linux-kernel, intel-gfx,
dri-devel, linux-modules, linux-trace-kernel
Cc: Yury Norov (NVIDIA)
In-Reply-To: <20251129195304.204082-1-yury.norov@gmail.com>
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
^ permalink raw reply related
* [PATCH 0/3] Unload linux/kernel.h
From: Yury Norov (NVIDIA) @ 2025-11-29 19:52 UTC (permalink / raw)
To: Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Andy Shevchenko, Randy Dunlap, Ingo Molnar, Jani Nikula,
Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin, Petr Pavlu,
Daniel Gomez, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, Andrew Morton, linux-kernel, intel-gfx,
dri-devel, linux-modules, linux-trace-kernel
Cc: 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
^ permalink raw reply
* [PATCH v3 7/7] kallsyms: Prevent module removal when printing module name and buildid
From: Petr Mladek @ 2025-11-28 13:59 UTC (permalink / raw)
To: Petr Pavlu, Steven Rostedt, Alexei Starovoitov, Andrew Morton,
Kees Cook
Cc: Aaron Tomlin, Daniel Borkmann, John Fastabend, Masami Hiramatsu,
Mark Rutland, Luis Chamberlain, Daniel Gomez, Sami Tolvanen,
linux-kernel, bpf, linux-modules, linux-trace-kernel, Petr Mladek
In-Reply-To: <20251128135920.217303-1-pmladek@suse.com>
kallsyms_lookup_buildid() copies the symbol name into the given buffer
so that it can be safely read anytime later. But it just copies pointers
to mod->name and mod->build_id which might get reused after the related
struct module gets removed.
The lifetime of struct module is synchronized using RCU. Take the rcu
read lock for the entire __sprint_symbol().
Reviewed-by: Aaron Tomlin <atomlin@atomlin.com>
Signed-off-by: Petr Mladek <pmladek@suse.com>
---
kernel/kallsyms.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/kernel/kallsyms.c b/kernel/kallsyms.c
index 5bc1646f8639..202d39f5493a 100644
--- a/kernel/kallsyms.c
+++ b/kernel/kallsyms.c
@@ -471,6 +471,9 @@ static int __sprint_symbol(char *buffer, unsigned long address,
unsigned long offset, size;
int len;
+ /* Prevent module removal until modname and modbuildid are printed */
+ guard(rcu)();
+
address += symbol_offset;
len = kallsyms_lookup_buildid(address, &size, &offset, &modname, &buildid,
buffer);
--
2.52.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox