* Re: [PATCH v3 4/4] tracing: move tracing declarations from kernel.h to a dedicated header
From: Randy Dunlap @ 2025-12-18 18:34 UTC (permalink / raw)
To: Steven Rostedt, Yury Norov
Cc: Andrew Morton, Masami Hiramatsu, Mathieu Desnoyers,
Andy Shevchenko, Christophe Leroy, Ingo Molnar, Jani Nikula,
Joonas Lahtinen, David Laight, Petr Pavlu, Andi Shyti,
Rodrigo Vivi, Tvrtko Ursulin, Daniel Gomez, Greg Kroah-Hartman,
Rafael J. Wysocki, Danilo Krummrich, linux-kernel, intel-gfx,
dri-devel, linux-modules, linux-trace-kernel, Kees Cook
In-Reply-To: <20251218123349.35339242@gandalf.local.home>
On 12/18/25 9:33 AM, Steven Rostedt wrote:
> On Wed, 17 Dec 2025 22:59:33 -0500
> Yury Norov <yury.norov@gmail.com> wrote:
>
>> I deem to drop trace_printk.h from kernel.h - it is more aligned with
>> the idea of unloading the header. The original motivation to keep
>> trace_printk.h in kernel.h was just because a similar printk.h is living
>> there. But after all, this is a purely debugging header, so no need for
>> almost every C file to bear debugging stuff.
>
> It is a big deal for debugging stuff. A lot of developers debug their code
> with trace_printk(), and do the "shotgun approach", where they cut and
> paste trace_printk()s all over their code in several files. Having to now add:
>
> #include <linux/trace_printk.h>
>
> whenever a trace_printk() is added is going to be a big PITA and slow down
> all debugging efforts.
Eh? Maybe a PITA, but surely not a big one.
Slow down "all debugging efforts?"
Please cut down on the hyperbole.
--
~Randy
^ permalink raw reply
* Re: [PATCH v3 4/4] tracing: move tracing declarations from kernel.h to a dedicated header
From: Steven Rostedt @ 2025-12-18 17:43 UTC (permalink / raw)
To: Yury Norov
Cc: Randy Dunlap, Andrew Morton, Masami Hiramatsu, Mathieu Desnoyers,
Andy Shevchenko, Christophe Leroy, Ingo Molnar, Jani Nikula,
Joonas Lahtinen, David Laight, Petr Pavlu, Andi Shyti,
Rodrigo Vivi, Tvrtko Ursulin, Daniel Gomez, Greg Kroah-Hartman,
Rafael J. Wysocki, Danilo Krummrich, linux-kernel, intel-gfx,
dri-devel, linux-modules, linux-trace-kernel, Kees Cook
In-Reply-To: <20251218123349.35339242@gandalf.local.home>
On Thu, 18 Dec 2025 12:33:49 -0500
Steven Rostedt <rostedt@goodmis.org> wrote:
> On Wed, 17 Dec 2025 22:59:33 -0500
> Yury Norov <yury.norov@gmail.com> wrote:
>
> > I deem to drop trace_printk.h from kernel.h - it is more aligned with
> > the idea of unloading the header. The original motivation to keep
> > trace_printk.h in kernel.h was just because a similar printk.h is living
> > there. But after all, this is a purely debugging header, so no need for
> > almost every C file to bear debugging stuff.
>
> It is a big deal for debugging stuff. A lot of developers debug their code
> with trace_printk(), and do the "shotgun approach", where they cut and
> paste trace_printk()s all over their code in several files. Having to now add:
>
> #include <linux/trace_printk.h>
>
> whenever a trace_printk() is added is going to be a big PITA and slow down
> all debugging efforts.
>
I don't actually remember why I had __trace_puts() pass in the size. I
could change it to:
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 5b46924fdff5..d5a939b8c391 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -331,10 +331,10 @@ int __trace_printk(unsigned long ip, const char *fmt, ...);
if (__builtin_constant_p(str)) \
__trace_bputs(_THIS_IP_, trace_printk_fmt); \
else \
- __trace_puts(_THIS_IP_, str, strlen(str)); \
+ __trace_puts(_THIS_IP_, str); \
})
extern int __trace_bputs(unsigned long ip, const char *str);
-extern int __trace_puts(unsigned long ip, const char *str, int size);
+extern int __trace_puts(unsigned long ip, const char *str);
extern void trace_dump_stack(int skip);
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index e575956ef9b5..686741edb803 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -1178,11 +1178,10 @@ EXPORT_SYMBOL_GPL(__trace_array_puts);
* __trace_puts - write a constant string into the trace buffer.
* @ip: The address of the caller
* @str: The constant string to write
- * @size: The size of the string.
*/
-int __trace_puts(unsigned long ip, const char *str, int size)
+int __trace_puts(unsigned long ip, const char *str)
{
- return __trace_array_puts(printk_trace, ip, str, size);
+ return __trace_array_puts(printk_trace, ip, str, strlen(str));
}
EXPORT_SYMBOL_GPL(__trace_puts);
@@ -1201,7 +1200,7 @@ int __trace_bputs(unsigned long ip, const char *str)
int size = sizeof(struct bputs_entry);
if (!printk_binsafe(tr))
- return __trace_puts(ip, str, strlen(str));
+ return __trace_puts(ip, str);
if (!(tr->trace_flags & TRACE_ITER(PRINTK)))
return 0;
diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index b6d42fe06115..de4e6713b84e 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -2116,7 +2116,7 @@ extern void tracing_log_err(struct trace_array *tr,
* about performance). The internal_trace_puts() is for such
* a purpose.
*/
-#define internal_trace_puts(str) __trace_puts(_THIS_IP_, str, strlen(str))
+#define internal_trace_puts(str) __trace_puts(_THIS_IP_, str)
#undef FTRACE_ENTRY
#define FTRACE_ENTRY(call, struct_name, id, tstruct, print) \
Which removes the strlen() altogether.
-- Steve
^ permalink raw reply related
* Re: [PATCH v3 4/4] tracing: move tracing declarations from kernel.h to a dedicated header
From: Steven Rostedt @ 2025-12-18 17:33 UTC (permalink / raw)
To: Yury Norov
Cc: Randy Dunlap, Andrew Morton, Masami Hiramatsu, Mathieu Desnoyers,
Andy Shevchenko, Christophe Leroy, Ingo Molnar, Jani Nikula,
Joonas Lahtinen, David Laight, Petr Pavlu, Andi Shyti,
Rodrigo Vivi, Tvrtko Ursulin, Daniel Gomez, Greg Kroah-Hartman,
Rafael J. Wysocki, Danilo Krummrich, linux-kernel, intel-gfx,
dri-devel, linux-modules, linux-trace-kernel, Kees Cook
In-Reply-To: <aUN8Hm377C5A0ILX@yury>
On Wed, 17 Dec 2025 22:59:33 -0500
Yury Norov <yury.norov@gmail.com> wrote:
> I deem to drop trace_printk.h from kernel.h - it is more aligned with
> the idea of unloading the header. The original motivation to keep
> trace_printk.h in kernel.h was just because a similar printk.h is living
> there. But after all, this is a purely debugging header, so no need for
> almost every C file to bear debugging stuff.
It is a big deal for debugging stuff. A lot of developers debug their code
with trace_printk(), and do the "shotgun approach", where they cut and
paste trace_printk()s all over their code in several files. Having to now add:
#include <linux/trace_printk.h>
whenever a trace_printk() is added is going to be a big PITA and slow down
all debugging efforts.
-- Steve
^ permalink raw reply
* Re: [PATCH v3 0/7] kallsyms: Prevent invalid access when showing module buildid
From: Petr Mladek @ 2025-12-18 9:09 UTC (permalink / raw)
To: Andrew Morton
Cc: Petr Pavlu, Steven Rostedt, Alexei Starovoitov, Kees Cook,
Aaron Tomlin, Daniel Borkmann, John Fastabend, Masami Hiramatsu,
Mark Rutland, Luis Chamberlain, Daniel Gomez, Sami Tolvanen,
linux-kernel, bpf, linux-modules, linux-trace-kernel
In-Reply-To: <20251217130904.33163c243172324a5308efe9@linux-foundation.org>
On Wed 2025-12-17 13:09:04, Andrew Morton wrote:
> On Fri, 28 Nov 2025 14:59:13 +0100 Petr Mladek <pmladek@suse.com> wrote:
>
> > This patchset is cleaning up kallsyms code related to module buildid.
> > It is fixing an invalid access when printing backtraces, see [v1] for
> > more details:
> >
> > ...
> >
> > [v1] https://lore.kernel.org/r/20251105142319.1139183-1-pmladek@suse.com
> > [v2] https://lore.kernel.org/r/20251112142003.182062-1-pmladek@suse.com
> >
>
> It's best to avoid sending people off to the WWW to understand a
> patchset - better that the git history be self-contained.
I see. I'll do better next time.
> So when
> staging this for mm.git I scooped the relevant material from [1] and
> added it to your cover letter, as below. Looks OK?
It looks OK to me. Thanks for taking the patchset.
Best Regards,
Petr
^ permalink raw reply
* Re: [PATCH v3 4/4] tracing: move tracing declarations from kernel.h to a dedicated header
From: Randy Dunlap @ 2025-12-18 5:59 UTC (permalink / raw)
To: Yury Norov
Cc: Andrew Morton, Steven Rostedt, Masami Hiramatsu,
Mathieu Desnoyers, Andy Shevchenko, Christophe Leroy, Ingo Molnar,
Jani Nikula, Joonas Lahtinen, David Laight, Petr Pavlu,
Andi Shyti, Rodrigo Vivi, Tvrtko Ursulin, Daniel Gomez,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
linux-kernel, intel-gfx, dri-devel, linux-modules,
linux-trace-kernel, Kees Cook
In-Reply-To: <aUN8Hm377C5A0ILX@yury>
On 12/17/25 7:59 PM, Yury Norov wrote:
> On Tue, Dec 16, 2025 at 09:24:55PM -0800, Randy Dunlap wrote:
>> [adding Kees]
>>
>> On 12/16/25 4:13 PM, Andrew Morton wrote:
>>> On Fri, 5 Dec 2025 12:52:35 -0500 "Yury Norov (NVIDIA)" <yury.norov@gmail.com> wrote:
>>>
>>>> Tracing is a half of the kernel.h in terms of LOCs, although it's
>>>> a self-consistent part. It is intended for quick debugging purposes
>>>> and isn't used by the normal tracing utilities.
>>>>
>>>> Move it to a separate header. If someone needs to just throw a
>>>> trace_printk() in their driver, they will not have to pull all
>>>> the heavy tracing machinery.
>>>>
>>>> This is a pure move, except for removing a few 'extern's.
>>>>
>>
>> Hm, for a pure move, this shouldn't be necessary. Anyway, not using
>> FORTIFY in purgatory.o fixes this build error.
>> Or maybe there's a better answer.
>>
>> ---
>> arch/x86/purgatory/Makefile | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> --- a/arch/x86/purgatory/Makefile
>> +++ b/arch/x86/purgatory/Makefile
>> @@ -62,7 +62,7 @@ PURGATORY_CFLAGS_REMOVE += $(CC_FLAGS_C
>> endif
>>
>> CFLAGS_REMOVE_purgatory.o += $(PURGATORY_CFLAGS_REMOVE)
>> -CFLAGS_purgatory.o += $(PURGATORY_CFLAGS)
>> +CFLAGS_purgatory.o += $(PURGATORY_CFLAGS) -D__NO_FORTIFY
>>
>> CFLAGS_REMOVE_sha256.o += $(PURGATORY_CFLAGS_REMOVE)
>> CFLAGS_sha256.o += $(PURGATORY_CFLAGS)
>
> That happened because the new trace_printk.h includes string.h for
> strlen(), so all kernel.h users now indirectly include it, and it
> causes, seemingly, a circular dependency if FORTIFY is enabled.
>
> A fix would be dropping trace_printk.h from kernel.h, or switching the
> only user of string.h, trace_puts(), to __builtin_strlen().
>
> Notice, Andy has concerned about this on the previous round, and also
> suggested __builtin_strlen():
>
> https://lkml.org/lkml/2025/12/3/910
>
> I deem to drop trace_printk.h from kernel.h - it is more aligned with
> the idea of unloading the header. The original motivation to keep
> trace_printk.h in kernel.h was just because a similar printk.h is living
> there. But after all, this is a purely debugging header, so no need for
> almost every C file to bear debugging stuff.
>
> I can actually do both - switch to an intrinsic and drop the header.
>
> Guys, please let me know what do you thing.
There are some problems with using __builtin_mem{cpy,set} -- don't
know about __builtin_str{whatever}. See
commit 4ce97317f41d
Author: Nick Desaulniers <nick.desaulniers+lkml@gmail.com>
Date: Wed Aug 7 15:15:32 2019 -0700
x86/purgatory: Do not use __builtin_memcpy and __builtin_memset
We should drop the header from kernel.h soon anyway, whether now or
in a few weeks/months. IMHO.
--
~Randy
^ permalink raw reply
* Re: [PATCH v3 4/4] tracing: move tracing declarations from kernel.h to a dedicated header
From: Yury Norov @ 2025-12-18 3:59 UTC (permalink / raw)
To: Randy Dunlap
Cc: Andrew Morton, Steven Rostedt, Masami Hiramatsu,
Mathieu Desnoyers, Andy Shevchenko, Christophe Leroy, Ingo Molnar,
Jani Nikula, Joonas Lahtinen, David Laight, Petr Pavlu,
Andi Shyti, Rodrigo Vivi, Tvrtko Ursulin, Daniel Gomez,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
linux-kernel, intel-gfx, dri-devel, linux-modules,
linux-trace-kernel, Kees Cook
In-Reply-To: <55ceb7bf-0fe9-4edc-81c2-d51366847eec@infradead.org>
On Tue, Dec 16, 2025 at 09:24:55PM -0800, Randy Dunlap wrote:
> [adding Kees]
>
> On 12/16/25 4:13 PM, Andrew Morton wrote:
> > On Fri, 5 Dec 2025 12:52:35 -0500 "Yury Norov (NVIDIA)" <yury.norov@gmail.com> wrote:
> >
> >> Tracing is a half of the kernel.h in terms of LOCs, although it's
> >> a self-consistent part. It is intended for quick debugging purposes
> >> and isn't used by the normal tracing utilities.
> >>
> >> Move it to a separate header. If someone needs to just throw a
> >> trace_printk() in their driver, they will not have to pull all
> >> the heavy tracing machinery.
> >>
> >> This is a pure move, except for removing a few 'extern's.
> >>
>
> Hm, for a pure move, this shouldn't be necessary. Anyway, not using
> FORTIFY in purgatory.o fixes this build error.
> Or maybe there's a better answer.
>
> ---
> arch/x86/purgatory/Makefile | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- a/arch/x86/purgatory/Makefile
> +++ b/arch/x86/purgatory/Makefile
> @@ -62,7 +62,7 @@ PURGATORY_CFLAGS_REMOVE += $(CC_FLAGS_C
> endif
>
> CFLAGS_REMOVE_purgatory.o += $(PURGATORY_CFLAGS_REMOVE)
> -CFLAGS_purgatory.o += $(PURGATORY_CFLAGS)
> +CFLAGS_purgatory.o += $(PURGATORY_CFLAGS) -D__NO_FORTIFY
>
> CFLAGS_REMOVE_sha256.o += $(PURGATORY_CFLAGS_REMOVE)
> CFLAGS_sha256.o += $(PURGATORY_CFLAGS)
That happened because the new trace_printk.h includes string.h for
strlen(), so all kernel.h users now indirectly include it, and it
causes, seemingly, a circular dependency if FORTIFY is enabled.
A fix would be dropping trace_printk.h from kernel.h, or switching the
only user of string.h, trace_puts(), to __builtin_strlen().
Notice, Andy has concerned about this on the previous round, and also
suggested __builtin_strlen():
https://lkml.org/lkml/2025/12/3/910
I deem to drop trace_printk.h from kernel.h - it is more aligned with
the idea of unloading the header. The original motivation to keep
trace_printk.h in kernel.h was just because a similar printk.h is living
there. But after all, this is a purely debugging header, so no need for
almost every C file to bear debugging stuff.
I can actually do both - switch to an intrinsic and drop the header.
Guys, please let me know what do you thing.
Thanks,
Yury
^ permalink raw reply
* Re: [PATCH v3 0/7] kallsyms: Prevent invalid access when showing module buildid
From: Andrew Morton @ 2025-12-17 21:10 UTC (permalink / raw)
To: Petr Mladek
Cc: Petr Pavlu, Steven Rostedt, Alexei Starovoitov, Kees Cook,
Aaron Tomlin, Daniel Borkmann, John Fastabend, Masami Hiramatsu,
Mark Rutland, Luis Chamberlain, Daniel Gomez, Sami Tolvanen,
linux-kernel, bpf, linux-modules, linux-trace-kernel
In-Reply-To: <aUFl9n3b8DWnYGyJ@pathway.suse.cz>
On Tue, 16 Dec 2025 15:00:22 +0100 Petr Mladek <pmladek@suse.com> wrote:
> I wonder who could take this patchset.
>
> IMHO, the failed test report is bogus. The system went out of memory.
> Anyway, the info provided by the mail is not enough for debugging.
>
> IMHO. this patchset is ready for linux-next. Unfortunately, kallsyms
> do not have any dedicated maintainer. I though about Kees (hardening)
> or Andrew (core stuff). Or I could take it via printk tree.
I seem to be a usual kallsyms patch monkey so I scooped it up, thanks.
If you or Kees prefer to take it then I'll drop the mm.git copy when I
get notified of the duplication by the linux-next maintainer.
^ permalink raw reply
* Re: [PATCH v3 0/7] kallsyms: Prevent invalid access when showing module buildid
From: Andrew Morton @ 2025-12-17 21:09 UTC (permalink / raw)
To: Petr Mladek
Cc: Petr Pavlu, Steven Rostedt, Alexei Starovoitov, Kees Cook,
Aaron Tomlin, Daniel Borkmann, John Fastabend, Masami Hiramatsu,
Mark Rutland, Luis Chamberlain, Daniel Gomez, Sami Tolvanen,
linux-kernel, bpf, linux-modules, linux-trace-kernel
In-Reply-To: <20251128135920.217303-1-pmladek@suse.com>
On Fri, 28 Nov 2025 14:59:13 +0100 Petr Mladek <pmladek@suse.com> wrote:
> This patchset is cleaning up kallsyms code related to module buildid.
> It is fixing an invalid access when printing backtraces, see [v1] for
> more details:
>
> ...
>
> [v1] https://lore.kernel.org/r/20251105142319.1139183-1-pmladek@suse.com
> [v2] https://lore.kernel.org/r/20251112142003.182062-1-pmladek@suse.com
>
It's best to avoid sending people off to the WWW to understand a
patchset - better that the git history be self-contained. So when
staging this for mm.git I scooped the relevant material from [1] and
added it to your cover letter, as below. Looks OK?
From: Petr Mladek <pmladek@suse.com>
Subject: kallsyms: clean up @namebuf initialization in kallsyms_lookup_buildid()
Date: Fri, 28 Nov 2025 14:59:14 +0100
Patch series "kallsyms: Prevent invalid access when showing module
buildid", v3.
We have seen nested crashes in __sprint_symbol(), see below. They seem to
be caused by an invalid pointer to "buildid". This patchset cleans up
kallsyms code related to module buildid and fixes this invalid access when
printing backtraces.
I made an audit of __sprint_symbol() and found several situations
when the buildid might be wrong:
+ bpf_address_lookup() does not set @modbuildid
+ ftrace_mod_address_lookup() does not set @modbuildid
+ __sprint_symbol() does not take rcu_read_lock and
the related struct module might get removed before
mod->build_id is printed.
This patchset solves these problems:
+ 1st, 2nd patches are preparatory
+ 3rd, 4th, 6th patches fix the above problems
+ 5th patch cleans up a suspicious initialization code.
This is the backtrace, we have seen. But it is not really important.
The problems fixed by the patchset are obvious:
crash64> bt [62/2029]
PID: 136151 TASK: ffff9f6c981d4000 CPU: 367 COMMAND: "btrfs"
#0 [ffffbdb687635c28] machine_kexec at ffffffffb4c845b3
#1 [ffffbdb687635c80] __crash_kexec at ffffffffb4d86a6a
#2 [ffffbdb687635d08] hex_string at ffffffffb51b3b61
#3 [ffffbdb687635d40] crash_kexec at ffffffffb4d87964
#4 [ffffbdb687635d50] oops_end at ffffffffb4c41fc8
#5 [ffffbdb687635d70] do_trap at ffffffffb4c3e49a
#6 [ffffbdb687635db8] do_error_trap at ffffffffb4c3e6a4
#7 [ffffbdb687635df8] exc_stack_segment at ffffffffb5666b33
#8 [ffffbdb687635e20] asm_exc_stack_segment at ffffffffb5800cf9
...
This patch (of 7)
The function kallsyms_lookup_buildid() initializes the given @namebuf by
clearing the first and the last byte. It is not clear why.
The 1st byte makes sense because some callers ignore the return code and
expect that the buffer contains a valid string, for example:
- function_stat_show()
- kallsyms_lookup()
- kallsyms_lookup_buildid()
The initialization of the last byte does not make much sense because it
can later be overwritten. Fortunately, it seems that all called functions
behave correctly:
- kallsyms_expand_symbol() explicitly adds the trailing '\0'
at the end of the function.
- All *__address_lookup() functions either use the safe strscpy()
or they do not touch the buffer at all.
Document the reason for clearing the first byte. And remove the useless
initialization of the last byte.
Link: https://lkml.kernel.org/r/20251128135920.217303-2-pmladek@suse.com
Signed-off-by: Petr Mladek <pmladek@suse.com>
Reviewed-by: Aaron Tomlin <atomlin@atomlin.com>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Daniel Borkman <daniel@iogearbox.net>
Cc: John Fastabend <john.fastabend@gmail.com>
Cc: Kees Cook <kees@kernel.org>
Cc: Luis Chamberalin <mcgrof@kernel.org>
Cc: Marc Rutland <mark.rutland@arm.com>
Cc: "Masami Hiramatsu (Google)" <mhiramat@kernel.org>
Cc: Petr Pavlu <petr.pavlu@suse.com>
Cc: Sami Tolvanen <samitolvanen@google.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
kernel/kallsyms.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
--- a/kernel/kallsyms.c~kallsyms-clean-up-namebuf-initialization-in-kallsyms_lookup_buildid
+++ a/kernel/kallsyms.c
@@ -355,7 +355,12 @@ static int kallsyms_lookup_buildid(unsig
{
int ret;
- namebuf[KSYM_NAME_LEN - 1] = 0;
+ /*
+ * kallsyms_lookus() returns pointer to namebuf on success and
+ * NULL on error. But some callers ignore the return value.
+ * Instead they expect @namebuf filled either with valid
+ * or empty string.
+ */
namebuf[0] = 0;
if (is_ksym_addr(addr)) {
_
^ permalink raw reply
* Re: [PATCH v3 4/4] tracing: move tracing declarations from kernel.h to a dedicated header
From: Randy Dunlap @ 2025-12-17 5:24 UTC (permalink / raw)
To: Andrew Morton, Yury Norov (NVIDIA)
Cc: Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Andy Shevchenko, Christophe Leroy, Ingo Molnar, Jani Nikula,
Joonas Lahtinen, David Laight, Petr Pavlu, Andi Shyti,
Rodrigo Vivi, Tvrtko Ursulin, Daniel Gomez, Greg Kroah-Hartman,
Rafael J. Wysocki, Danilo Krummrich, linux-kernel, intel-gfx,
dri-devel, linux-modules, linux-trace-kernel, Kees Cook
In-Reply-To: <20251216161316.45b3f19ff0ad482018137189@linux-foundation.org>
[adding Kees]
On 12/16/25 4:13 PM, Andrew Morton wrote:
> On Fri, 5 Dec 2025 12:52:35 -0500 "Yury Norov (NVIDIA)" <yury.norov@gmail.com> wrote:
>
>> Tracing is a half of the kernel.h in terms of LOCs, although it's
>> a self-consistent part. It is intended for quick debugging purposes
>> and isn't used by the normal tracing utilities.
>>
>> Move it to a separate header. If someone needs to just throw a
>> trace_printk() in their driver, they will not have to pull all
>> the heavy tracing machinery.
>>
>> This is a pure move, except for removing a few 'extern's.
>>
Hm, for a pure move, this shouldn't be necessary. Anyway, not using
FORTIFY in purgatory.o fixes this build error.
Or maybe there's a better answer.
---
arch/x86/purgatory/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/x86/purgatory/Makefile
+++ b/arch/x86/purgatory/Makefile
@@ -62,7 +62,7 @@ PURGATORY_CFLAGS_REMOVE += $(CC_FLAGS_C
endif
CFLAGS_REMOVE_purgatory.o += $(PURGATORY_CFLAGS_REMOVE)
-CFLAGS_purgatory.o += $(PURGATORY_CFLAGS)
+CFLAGS_purgatory.o += $(PURGATORY_CFLAGS) -D__NO_FORTIFY
CFLAGS_REMOVE_sha256.o += $(PURGATORY_CFLAGS_REMOVE)
CFLAGS_sha256.o += $(PURGATORY_CFLAGS)
>
> This one blows up my x86_64 allmodconfig, gcc-15.2.0:
>
> In file included from ./include/linux/string.h:386,
> from ./include/linux/trace_printk.h:9,
> from ./include/linux/kernel.h:34,
> from arch/x86/purgatory/purgatory.c:12:
> ./include/linux/fortify-string.h:626:63: error: expected identifier or '(' before '{' token
> 626 | p_size_field, q_size_field, op) ({ \
> | ^
> ./include/linux/fortify-string.h:694:27: note: in expansion of macro '__fortify_memcpy_chk'
> 694 | #define memmove(p, q, s) __fortify_memcpy_chk(p, q, s, \
> | ^~~~~~~~~~~~~~~~~~~~
> arch/x86/purgatory/../boot/string.h:11:7: note: in expansion of macro 'memmove'
> 11 | void *memmove(void *dst, const void *src, size_t len);
> | ^~~~~~~
> ./include/linux/fortify-string.h:258:9: error: expected identifier or '(' before '__builtin_choose_expr'
> 258 | __builtin_choose_expr(__is_constexpr(__builtin_strlen(p)), \
> | ^~~~~~~~~~~~~~~~~~~~~
> arch/x86/purgatory/../boot/string.h:23:15: note: in expansion of macro 'strlen'
> 23 | extern size_t strlen(const char *s);
> | ^~~~~~
> make[4]: *** [scripts/Makefile.build:287: arch/x86/purgatory/purgatory.o] Error 1
> make[3]: *** [scripts/Makefile.build:556: arch/x86/purgatory] Error 2
> make[2]: *** [scripts/Makefile.build:556: arch/x86] Error 2
> make[1]: *** [/usr/src/25/Makefile:2054: .] Error 2
> make: *** [Makefile:248: __sub-make] Error 2
>
--
~Randy
^ permalink raw reply
* Re: [PATCH v3 4/4] tracing: move tracing declarations from kernel.h to a dedicated header
From: Yury Norov @ 2025-12-17 0:52 UTC (permalink / raw)
To: Andrew Morton
Cc: Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Andy Shevchenko, Christophe Leroy, Randy Dunlap, Ingo Molnar,
Jani Nikula, Joonas Lahtinen, David Laight, Petr Pavlu,
Andi Shyti, Rodrigo Vivi, Tvrtko Ursulin, Daniel Gomez,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
linux-kernel, intel-gfx, dri-devel, linux-modules,
linux-trace-kernel
In-Reply-To: <20251216161316.45b3f19ff0ad482018137189@linux-foundation.org>
On Tue, Dec 16, 2025 at 04:13:16PM -0800, Andrew Morton wrote:
> On Fri, 5 Dec 2025 12:52:35 -0500 "Yury Norov (NVIDIA)" <yury.norov@gmail.com> wrote:
>
> > Tracing is a half of the kernel.h in terms of LOCs, although it's
> > a self-consistent part. It is intended for quick debugging purposes
> > and isn't used by the normal tracing utilities.
> >
> > Move it to a separate header. If someone needs to just throw a
> > trace_printk() in their driver, they will not have to pull all
> > the heavy tracing machinery.
> >
> > This is a pure move, except for removing a few 'extern's.
> >
>
> This one blows up my x86_64 allmodconfig, gcc-15.2.0:
Thanks, Andrew. I'll take a look.
^ permalink raw reply
* Re: [PATCH v3 4/4] tracing: move tracing declarations from kernel.h to a dedicated header
From: Andrew Morton @ 2025-12-17 0:13 UTC (permalink / raw)
To: Yury Norov (NVIDIA)
Cc: Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Andy Shevchenko, Christophe Leroy, Randy Dunlap, Ingo Molnar,
Jani Nikula, Joonas Lahtinen, David Laight, Petr Pavlu,
Andi Shyti, Rodrigo Vivi, Tvrtko Ursulin, Daniel Gomez,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
linux-kernel, intel-gfx, dri-devel, linux-modules,
linux-trace-kernel
In-Reply-To: <20251205175237.242022-5-yury.norov@gmail.com>
On Fri, 5 Dec 2025 12:52:35 -0500 "Yury Norov (NVIDIA)" <yury.norov@gmail.com> wrote:
> Tracing is a half of the kernel.h in terms of LOCs, although it's
> a self-consistent part. It is intended for quick debugging purposes
> and isn't used by the normal tracing utilities.
>
> Move it to a separate header. If someone needs to just throw a
> trace_printk() in their driver, they will not have to pull all
> the heavy tracing machinery.
>
> This is a pure move, except for removing a few 'extern's.
>
This one blows up my x86_64 allmodconfig, gcc-15.2.0:
In file included from ./include/linux/string.h:386,
from ./include/linux/trace_printk.h:9,
from ./include/linux/kernel.h:34,
from arch/x86/purgatory/purgatory.c:12:
./include/linux/fortify-string.h:626:63: error: expected identifier or '(' before '{' token
626 | p_size_field, q_size_field, op) ({ \
| ^
./include/linux/fortify-string.h:694:27: note: in expansion of macro '__fortify_memcpy_chk'
694 | #define memmove(p, q, s) __fortify_memcpy_chk(p, q, s, \
| ^~~~~~~~~~~~~~~~~~~~
arch/x86/purgatory/../boot/string.h:11:7: note: in expansion of macro 'memmove'
11 | void *memmove(void *dst, const void *src, size_t len);
| ^~~~~~~
./include/linux/fortify-string.h:258:9: error: expected identifier or '(' before '__builtin_choose_expr'
258 | __builtin_choose_expr(__is_constexpr(__builtin_strlen(p)), \
| ^~~~~~~~~~~~~~~~~~~~~
arch/x86/purgatory/../boot/string.h:23:15: note: in expansion of macro 'strlen'
23 | extern size_t strlen(const char *s);
| ^~~~~~
make[4]: *** [scripts/Makefile.build:287: arch/x86/purgatory/purgatory.o] Error 1
make[3]: *** [scripts/Makefile.build:556: arch/x86/purgatory] Error 2
make[2]: *** [scripts/Makefile.build:556: arch/x86] Error 2
make[1]: *** [/usr/src/25/Makefile:2054: .] Error 2
make: *** [Makefile:248: __sub-make] Error 2
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: Update module subsystem maintainers and repository
From: Daniel Gomez @ 2025-12-16 18:44 UTC (permalink / raw)
To: Sami Tolvanen, Luis Chamberlain, Petr Pavlu
Cc: Aaron Tomlin, linux-modules, linux-kernel
In-Reply-To: <20251215215545.1332626-2-samitolvanen@google.com>
On 15/12/2025 22.55, Sami Tolvanen wrote:
> Add myself as a maintainer for module support as I'll be handling pull
> requests for the next six months according to the previously announced
> rotation [1][2]. Also, update the git repository link to point to the
> modules tree, which is already used by linux-next.
>
> Link: https://lore.kernel.org/linux-modules/Z3gDAnPlA3SZEbgl@bombadil.infradead.org [1]
> Link: https://lore.kernel.org/linux-modules/20251203234840.3720-1-da.gomez@kernel.org/ [2]
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
> ---
> MAINTAINERS | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 5b11839cba9d..0c18b87925f0 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -17613,12 +17613,12 @@ MODULE SUPPORT
> M: Luis Chamberlain <mcgrof@kernel.org>
> M: Petr Pavlu <petr.pavlu@suse.com>
> M: Daniel Gomez <da.gomez@kernel.org>
> -R: Sami Tolvanen <samitolvanen@google.com>
> +M: Sami Tolvanen <samitolvanen@google.com>
> R: Aaron Tomlin <atomlin@atomlin.com>
> L: linux-modules@vger.kernel.org
> L: linux-kernel@vger.kernel.org
> S: Maintained
> -T: git git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux.git modules-next
> +T: git git://git.kernel.org/pub/scm/linux/kernel/git/modules/linux.git modules-next
> F: include/linux/kmod.h
> F: include/linux/module*.h
> F: kernel/module/
>
> base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
Acked-by: Daniel Gomez <da.gomez@samsung.com>
^ permalink raw reply
* Re: [PATCH v3 0/7] kallsyms: Prevent invalid access when showing module buildid
From: Petr Mladek @ 2025-12-16 14:00 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
In-Reply-To: <20251128135920.217303-1-pmladek@suse.com>
Hi,
I wonder who could take this patchset.
IMHO, the failed test report is bogus. The system went out of memory.
Anyway, the info provided by the mail is not enough for debugging.
IMHO. this patchset is ready for linux-next. Unfortunately, kallsyms
do not have any dedicated maintainer. I though about Kees (hardening)
or Andrew (core stuff). Or I could take it via printk tree.
Best Regards,
Petr
On Fri 2025-11-28 14:59:13, Petr Mladek wrote:
> This patchset is cleaning up kallsyms code related to module buildid.
> It is fixing an invalid access when printing backtraces, see [v1] for
> more details:
>
> + 1st..4th patches are preparatory.
>
> + 5th and 6th patches are fixing bpf and ftrace related APIs.
>
> + 7th patch prevents a potential race.
>
>
> Changes against [v2]:
>
> + Fixed typos in commit message [Alexei]
>
> + Added Acks [Alexei]
>
>
> Changes against [v1]:
>
> + Added existing Reviewed-by tags.
>
> + Shuffled patches to update the kallsyms_lookup_buildid() initialization
> code 1st.
>
> + Initialized also *modname and *modbuildid in kallsyms_lookup_buildid().
>
> + Renamed __bpf_address_lookup() to bpf_address_lookup() and used it
> in kallsyms_lookup_buildid(). Did this instead of passing @modbuildid
> parameter just to clear it.
>
>
> [v1] https://lore.kernel.org/r/20251105142319.1139183-1-pmladek@suse.com
> [v2] https://lore.kernel.org/r/20251112142003.182062-1-pmladek@suse.com
>
>
> Petr Mladek (7):
> kallsyms: Clean up @namebuf initialization in
> kallsyms_lookup_buildid()
> kallsyms: Clean up modname and modbuildid initialization in
> kallsyms_lookup_buildid()
> module: Add helper function for reading module_buildid()
> kallsyms: Cleanup code for appending the module buildid
> kallsyms/bpf: Rename __bpf_address_lookup() to bpf_address_lookup()
> kallsyms/ftrace: Set module buildid in ftrace_mod_address_lookup()
> kallsyms: Prevent module removal when printing module name and buildid
>
> arch/arm64/net/bpf_jit_comp.c | 2 +-
> arch/powerpc/net/bpf_jit_comp.c | 2 +-
> include/linux/filter.h | 26 ++----------
> include/linux/ftrace.h | 6 ++-
> include/linux/module.h | 9 ++++
> kernel/bpf/core.c | 4 +-
> kernel/kallsyms.c | 73 ++++++++++++++++++++++++---------
> kernel/module/kallsyms.c | 9 +---
> kernel/trace/ftrace.c | 5 ++-
> 9 files changed, 81 insertions(+), 55 deletions(-)
>
> --
> 2.52.0
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: Update module subsystem maintainers and repository
From: Petr Pavlu @ 2025-12-16 8:57 UTC (permalink / raw)
To: Sami Tolvanen
Cc: Luis Chamberlain, Daniel Gomez, Aaron Tomlin, linux-modules,
linux-kernel
In-Reply-To: <20251215215545.1332626-2-samitolvanen@google.com>
On 12/15/25 10:55 PM, Sami Tolvanen wrote:
> Add myself as a maintainer for module support as I'll be handling pull
> requests for the next six months according to the previously announced
> rotation [1][2]. Also, update the git repository link to point to the
> modules tree, which is already used by linux-next.
>
> Link: https://lore.kernel.org/linux-modules/Z3gDAnPlA3SZEbgl@bombadil.infradead.org [1]
> Link: https://lore.kernel.org/linux-modules/20251203234840.3720-1-da.gomez@kernel.org/ [2]
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Acked-by: Petr Pavlu <petr.pavlu@suse.com>
--
Cheers,
Petr
^ permalink raw reply
* Re: [PATCH v3 1/4] kernel.h: drop STACK_MAGIC macro
From: Aaron Tomlin @ 2025-12-16 3:05 UTC (permalink / raw)
To: Yury Norov (NVIDIA)
Cc: Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Andy Shevchenko, Christophe Leroy, Randy Dunlap, Ingo Molnar,
Jani Nikula, Joonas Lahtinen, David Laight, Petr Pavlu,
Andi Shyti, Rodrigo Vivi, Tvrtko Ursulin, Daniel Gomez,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Andrew Morton, linux-kernel, intel-gfx, dri-devel, linux-modules,
linux-trace-kernel, Jani Nikula
In-Reply-To: <20251205175237.242022-2-yury.norov@gmail.com>
On Fri, Dec 05, 2025 at 12:52:32PM -0500, Yury Norov (NVIDIA) wrote:
> The macro was introduced in 1994, v1.0.4, for stacks protection. Since
> that, people found better ways to protect stacks, and now the macro is
> only used by i915 selftests. Move it to a local header and drop from
> the kernel.h.
>
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Acked-by: Randy Dunlap <rdunlap@infradead.org>
> Acked-by: Jani Nikula <jani.nikula@intel.com>
> Reviewed-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
> Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
> ---
> drivers/gpu/drm/i915/gt/selftest_ring_submission.c | 1 +
> drivers/gpu/drm/i915/i915_selftest.h | 2 ++
> include/linux/kernel.h | 2 --
> 3 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/selftest_ring_submission.c b/drivers/gpu/drm/i915/gt/selftest_ring_submission.c
> index 87ceb0f374b6..600333ae6c8c 100644
> --- a/drivers/gpu/drm/i915/gt/selftest_ring_submission.c
> +++ b/drivers/gpu/drm/i915/gt/selftest_ring_submission.c
> @@ -3,6 +3,7 @@
> * Copyright © 2020 Intel Corporation
> */
>
> +#include "i915_selftest.h"
> #include "intel_engine_pm.h"
> #include "selftests/igt_flush_test.h"
>
> diff --git a/drivers/gpu/drm/i915/i915_selftest.h b/drivers/gpu/drm/i915/i915_selftest.h
> index bdf3e22c0a34..72922028f4ba 100644
> --- a/drivers/gpu/drm/i915/i915_selftest.h
> +++ b/drivers/gpu/drm/i915/i915_selftest.h
> @@ -26,6 +26,8 @@
>
> #include <linux/types.h>
>
> +#define STACK_MAGIC 0xdeadbeef
> +
> struct pci_dev;
> struct drm_i915_private;
>
> 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
>
>
Reviewed-by: Aaron Tomlin <atomlin@atomlin.com>
--
Aaron Tomlin
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: Update module subsystem maintainers and repository
From: Aaron Tomlin @ 2025-12-15 22:00 UTC (permalink / raw)
To: Sami Tolvanen
Cc: Luis Chamberlain, Petr Pavlu, Daniel Gomez, linux-modules,
linux-kernel
In-Reply-To: <20251215215545.1332626-2-samitolvanen@google.com>
[-- Attachment #1: Type: text/plain, Size: 1630 bytes --]
On Mon, Dec 15, 2025 at 09:55:46PM +0000, Sami Tolvanen wrote:
> Add myself as a maintainer for module support as I'll be handling pull
> requests for the next six months according to the previously announced
> rotation [1][2]. Also, update the git repository link to point to the
> modules tree, which is already used by linux-next.
>
> Link: https://lore.kernel.org/linux-modules/Z3gDAnPlA3SZEbgl@bombadil.infradead.org [1]
> Link: https://lore.kernel.org/linux-modules/20251203234840.3720-1-da.gomez@kernel.org/ [2]
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
> ---
> MAINTAINERS | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 5b11839cba9d..0c18b87925f0 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -17613,12 +17613,12 @@ MODULE SUPPORT
> M: Luis Chamberlain <mcgrof@kernel.org>
> M: Petr Pavlu <petr.pavlu@suse.com>
> M: Daniel Gomez <da.gomez@kernel.org>
> -R: Sami Tolvanen <samitolvanen@google.com>
> +M: Sami Tolvanen <samitolvanen@google.com>
> R: Aaron Tomlin <atomlin@atomlin.com>
> L: linux-modules@vger.kernel.org
> L: linux-kernel@vger.kernel.org
> S: Maintained
> -T: git git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux.git modules-next
> +T: git git://git.kernel.org/pub/scm/linux/kernel/git/modules/linux.git modules-next
> F: include/linux/kmod.h
> F: include/linux/module*.h
> F: kernel/module/
>
> base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
> --
> 2.52.0.305.g3fc767764a-goog
>
Reviewed-by: Aaron Tomlin <atomlin@atomlin.com>
--
Aaron Tomlin
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH] MAINTAINERS: Update module subsystem maintainers and repository
From: Sami Tolvanen @ 2025-12-15 21:55 UTC (permalink / raw)
To: Luis Chamberlain, Petr Pavlu, Daniel Gomez
Cc: Aaron Tomlin, linux-modules, linux-kernel, Sami Tolvanen
Add myself as a maintainer for module support as I'll be handling pull
requests for the next six months according to the previously announced
rotation [1][2]. Also, update the git repository link to point to the
modules tree, which is already used by linux-next.
Link: https://lore.kernel.org/linux-modules/Z3gDAnPlA3SZEbgl@bombadil.infradead.org [1]
Link: https://lore.kernel.org/linux-modules/20251203234840.3720-1-da.gomez@kernel.org/ [2]
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
---
MAINTAINERS | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 5b11839cba9d..0c18b87925f0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -17613,12 +17613,12 @@ MODULE SUPPORT
M: Luis Chamberlain <mcgrof@kernel.org>
M: Petr Pavlu <petr.pavlu@suse.com>
M: Daniel Gomez <da.gomez@kernel.org>
-R: Sami Tolvanen <samitolvanen@google.com>
+M: Sami Tolvanen <samitolvanen@google.com>
R: Aaron Tomlin <atomlin@atomlin.com>
L: linux-modules@vger.kernel.org
L: linux-kernel@vger.kernel.org
S: Maintained
-T: git git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux.git modules-next
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/modules/linux.git modules-next
F: include/linux/kmod.h
F: include/linux/module*.h
F: kernel/module/
base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
--
2.52.0.305.g3fc767764a-goog
^ permalink raw reply related
* Re: [PATCH] modules: moduleparam.h: add kernel-doc comments
From: Petr Pavlu @ 2025-12-15 10:59 UTC (permalink / raw)
To: Randy Dunlap
Cc: Luis Chamberlain, Daniel Gomez, Sami Tolvanen, linux-modules,
linux-kernel
In-Reply-To: <20251214202357.2208303-1-rdunlap@infradead.org>
On 12/14/25 9:23 PM, Randy Dunlap wrote:
> Add missing kernel-doc comments to prevent kernel-doc warnings:
>
> Warning: include/linux/moduleparam.h:364 function parameter 'arg' not
> described in '__core_param_cb'
> Warning: include/linux/moduleparam.h:395 No description found for return
> value of 'parameq'
> Warning: include/linux/moduleparam.h:405 No description found for return
> value of 'parameqn'
>
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Nit: The description is somewhat misleading as it mentions adding
kernel-doc comments, but the patch actually involves fixing the existing
comments. I guess this can be adjusted by a maintainer who picks up the
patch and there is no need to resend it.
Looks ok to me otherwise.
Reviewed-by: Petr Pavlu <petr.pavlu@suse.com>
--
Thanks,
Petr
^ permalink raw reply
* Re: [PATCH v18 25/42] dept: add documents for dept
From: Bagas Sanjaya @ 2025-12-15 9:06 UTC (permalink / raw)
To: Byungchul Park
Cc: linux-kernel, kernel_team, torvalds, damien.lemoal, linux-ide,
adilger.kernel, linux-ext4, mingo, peterz, will, tglx, rostedt,
joel, sashal, daniel.vetter, duyuyang, johannes.berg, tj, tytso,
willy, david, amir73il, gregkh, kernel-team, linux-mm, akpm,
mhocko, minchan, hannes, vdavydov.dev, sj, jglisse, dennis, cl,
penberg, rientjes, vbabka, ngupta, linux-block, josef,
linux-fsdevel, jack, jlayton, dan.j.williams, hch, djwong,
dri-devel, rodrigosiqueiramelo, melissa.srw, hamohammed.sa,
harry.yoo, chris.p.wilson, gwan-gyeong.mun, max.byungchul.park,
boqun.feng, longman, yunseong.kim, ysk, yeoreum.yun, netdev,
matthew.brost, her0gyugyu, corbet, catalin.marinas, bp, x86, hpa,
luto, sumit.semwal, gustavo, christian.koenig, andi.shyti, arnd,
lorenzo.stoakes, Liam.Howlett, rppt, surenb, mcgrof, petr.pavlu,
da.gomez, samitolvanen, paulmck, frederic, neeraj.upadhyay,
joelagnelf, josh, urezki, mathieu.desnoyers, jiangshanlai,
qiang.zhang, juri.lelli, vincent.guittot, dietmar.eggemann,
bsegall, mgorman, vschneid, chuck.lever, neil, okorniev, Dai.Ngo,
tom, trondmy, anna, kees, bigeasy, clrkwllms, mark.rutland,
ada.coupriediaz, kristina.martsenko, wangkefeng.wang, broonie,
kevin.brodsky, dwmw, shakeel.butt, ast, ziy, yuzhao, baolin.wang,
usamaarif642, joel.granados, richard.weiyang, geert+renesas,
tim.c.chen, linux, alexander.shishkin, lillian, chenhuacai,
francesco, guoweikang.kernel, link, jpoimboe, masahiroy, brauner,
thomas.weissschuh, oleg, mjguzik, andrii, wangfushuai, linux-doc,
linux-arm-kernel, linux-media, linaro-mm-sig, linux-i2c,
linux-arch, linux-modules, rcu, linux-nfs, linux-rt-devel,
2407018371, dakr, miguel.ojeda.sandonis, neilb, wsa+renesas,
dave.hansen, geert, ojeda, alex.gaynor, gary, bjorn3_gh, lossin,
a.hindborg, aliceryhl, tmgross, rust-for-linux
In-Reply-To: <20251215042237.GA49936@system.software.com>
[-- Attachment #1: Type: text/plain, Size: 11104 bytes --]
On Mon, Dec 15, 2025 at 01:22:37PM +0900, Byungchul Park wrote:
> On Sat, Dec 06, 2025 at 07:25:22AM +0700, Bagas Sanjaya wrote:
> > On Fri, Dec 05, 2025 at 04:18:38PM +0900, Byungchul Park wrote:
> > > Add documents describing the concept and APIs of dept.
> > >
> > > Signed-off-by: Byungchul Park <byungchul@sk.com>
> > > ---
> > > Documentation/dev-tools/dept.rst | 778 +++++++++++++++++++++++++++
> > > Documentation/dev-tools/dept_api.rst | 125 +++++
> >
> > You forget to add toctree entries:
>
> I'm sorry for late reply.
>
> Thanks a lot!
>
> > ---- >8 ----
> > diff --git a/Documentation/dev-tools/index.rst b/Documentation/dev-tools/index.rst
> > index 4b8425e348abd1..02c858f5ed1fa2 100644
> > --- a/Documentation/dev-tools/index.rst
> > +++ b/Documentation/dev-tools/index.rst
> > @@ -22,6 +22,8 @@ Documentation/process/debugging/index.rst
> > clang-format
> > coccinelle
> > sparse
> > + dept
> > + dept_api
> > kcov
> > gcov
> > kasan
> >
> > > +Lockdep detects a deadlock by checking lock acquisition order. For
> > > +example, a graph to track acquisition order built by lockdep might look
> > > +like:
> > > +
> > > +.. literal::
> > > +
> > > + A -> B -
> > > + \
> > > + -> E
> > > + /
> > > + C -> D -
> > > +
> > > + where 'A -> B' means that acquisition A is prior to acquisition B
> > > + with A still held.
> >
> > Use code-block directive for literal code blocks:
>
> I will.
>
> > ---- >8 ----
> > diff --git a/Documentation/dev-tools/dept.rst b/Documentation/dev-tools/dept.rst
> > index 333166464543d7..8394c4ea81bc2a 100644
> > --- a/Documentation/dev-tools/dept.rst
> > +++ b/Documentation/dev-tools/dept.rst
> > @@ -10,7 +10,7 @@ Lockdep detects a deadlock by checking lock acquisition order. For
> > example, a graph to track acquisition order built by lockdep might look
> > like:
> >
> > -.. literal::
> > +.. code-block::
> >
> > A -> B -
> > \
> > @@ -25,7 +25,7 @@ Lockdep keeps adding each new acquisition order into the graph at
> > runtime. For example, 'E -> C' will be added when the two locks have
> > been acquired in the order, E and then C. The graph will look like:
> >
> > -.. literal::
> > +.. code-block::
> >
> > A -> B -
> > \
> > @@ -41,7 +41,7 @@ been acquired in the order, E and then C. The graph will look like:
> >
> > This graph contains a subgraph that demonstrates a loop like:
> >
> > -.. literal::
> > +.. code-block::
> >
> > -> E -
> > / \
> > @@ -76,7 +76,7 @@ e.g. irq context, normal process context, wq worker context, or so on.
> >
> > Can lockdep detect the following deadlock?
> >
> > -.. literal::
> > +.. code-block::
> >
> > context X context Y context Z
> >
> > @@ -91,7 +91,7 @@ Can lockdep detect the following deadlock?
> >
> > No. What about the following?
> >
> > -.. literal::
> > +.. code-block::
> >
> > context X context Y
> >
> > @@ -116,7 +116,7 @@ What leads a deadlock
> > A deadlock occurs when one or multi contexts are waiting for events that
> > will never happen. For example:
> >
> > -.. literal::
> > +.. code-block::
> >
> > context X context Y context Z
> >
> > @@ -148,7 +148,7 @@ In terms of dependency:
> >
> > Dependency graph reflecting this example will look like:
> >
> > -.. literal::
> > +.. code-block::
> >
> > -> C -> A -> B -
> > / \
> > @@ -171,7 +171,7 @@ Introduce DEPT
> > DEPT(DEPendency Tracker) tracks wait and event instead of lock
> > acquisition order so as to recognize the following situation:
> >
> > -.. literal::
> > +.. code-block::
> >
> > context X context Y context Z
> >
> > @@ -186,7 +186,7 @@ acquisition order so as to recognize the following situation:
> > and builds up a dependency graph at runtime that is similar to lockdep.
> > The graph might look like:
> >
> > -.. literal::
> > +.. code-block::
> >
> > -> C -> A -> B -
> > / \
> > @@ -199,7 +199,7 @@ DEPT keeps adding each new dependency into the graph at runtime. For
> > example, 'B -> D' will be added when event D occurrence is a
> > prerequisite to reaching event B like:
> >
> > -.. literal::
> > +.. code-block::
> >
> > context W
> >
> > @@ -211,7 +211,7 @@ prerequisite to reaching event B like:
> >
> > After the addition, the graph will look like:
> >
> > -.. literal::
> > +.. code-block::
> >
> > -> D
> > /
> > @@ -236,7 +236,7 @@ How DEPT works
> > Let's take a look how DEPT works with the 1st example in the section
> > 'Limitation of lockdep'.
> >
> > -.. literal::
> > +.. code-block::
> >
> > context X context Y context Z
> >
> > @@ -256,7 +256,7 @@ event.
> >
> > Adding comments to describe DEPT's view in detail:
> >
> > -.. literal::
> > +.. code-block::
> >
> > context X context Y context Z
> >
> > @@ -293,7 +293,7 @@ Adding comments to describe DEPT's view in detail:
> >
> > Let's build up dependency graph with this example. Firstly, context X:
> >
> > -.. literal::
> > +.. code-block::
> >
> > context X
> >
> > @@ -304,7 +304,7 @@ Let's build up dependency graph with this example. Firstly, context X:
> >
> > There are no events to create dependency. Next, context Y:
> >
> > -.. literal::
> > +.. code-block::
> >
> > context Y
> >
> > @@ -332,7 +332,7 @@ event A cannot be triggered if wait B cannot be awakened by event B.
> > Therefore, we can say event A depends on event B, say, 'A -> B'. The
> > graph will look like after adding the dependency:
> >
> > -.. literal::
> > +.. code-block::
> >
> > A -> B
> >
> > @@ -340,7 +340,7 @@ graph will look like after adding the dependency:
> >
> > Lastly, context Z:
> >
> > -.. literal::
> > +.. code-block::
> >
> > context Z
> >
> > @@ -362,7 +362,7 @@ triggered if wait A cannot be awakened by event A. Therefore, we can
> > say event B depends on event A, say, 'B -> A'. The graph will look like
> > after adding the dependency:
> >
> > -.. literal::
> > +.. code-block::
> >
> > -> A -> B -
> > / \
> > @@ -386,7 +386,7 @@ Interpret DEPT report
> >
> > The following is the same example in the section 'How DEPT works'.
> >
> > -.. literal::
> > +.. code-block::
> >
> > context X context Y context Z
> >
> > @@ -425,7 +425,7 @@ We can simplify this by labeling each waiting point with [W], each
> > point where its event's context starts with [S] and each event with [E].
> > This example will look like after the labeling:
> >
> > -.. literal::
> > +.. code-block::
> >
> > context X context Y context Z
> >
> > @@ -443,7 +443,7 @@ DEPT uses the symbols [W], [S] and [E] in its report as described above.
> > The following is an example reported by DEPT for a real problem in
> > practice.
> >
> > -.. literal::
> > +.. code-block::
> >
> > Link: https://lore.kernel.org/lkml/6383cde5-cf4b-facf-6e07-1378a485657d@I-love.SAKURA.ne.jp/#t
> > Link: https://lore.kernel.org/lkml/1674268856-31807-1-git-send-email-byungchul.park@lge.com/
> > @@ -646,7 +646,7 @@ practice.
> >
> > Let's take a look at the summary that is the most important part.
> >
> > -.. literal::
> > +.. code-block::
> >
> > ---------------------------------------------------
> > summary
> > @@ -669,7 +669,7 @@ Let's take a look at the summary that is the most important part.
> >
> > The summary shows the following scenario:
> >
> > -.. literal::
> > +.. code-block::
> >
> > context A context B context ?(unknown)
> >
> > @@ -684,7 +684,7 @@ The summary shows the following scenario:
> >
> > Adding comments to describe DEPT's view in detail:
> >
> > -.. literal::
> > +.. code-block::
> >
> > context A context B context ?(unknown)
> >
> > @@ -711,7 +711,7 @@ Adding comments to describe DEPT's view in detail:
> >
> > Let's build up dependency graph with this report. Firstly, context A:
> >
> > -.. literal::
> > +.. code-block::
> >
> > context A
> >
> > @@ -735,7 +735,7 @@ unlock(&ni->ni_lock:0) depends on folio_unlock(&f1), say,
> >
> > The graph will look like after adding the dependency:
> >
> > -.. literal::
> > +.. code-block::
> >
> > unlock(&ni->ni_lock:0) -> folio_unlock(&f1)
> >
> > @@ -743,7 +743,7 @@ The graph will look like after adding the dependency:
> >
> > Secondly, context B:
> >
> > -.. literal::
> > +.. code-block::
> >
> > context B
> >
> > @@ -762,7 +762,7 @@ folio_unlock(&f1) depends on unlock(&ni->ni_lock:0), say,
> >
> > The graph will look like after adding the dependency:
> >
> > -.. literal::
> > +.. code-block::
> >
> > -> unlock(&ni->ni_lock:0) -> folio_unlock(&f1) -
> > / \
> >
> > > +Limitation of lockdep
> > > +---------------------
> > > +
> > > +Lockdep deals with a deadlock by typical lock e.g. spinlock and mutex,
> > > +that are supposed to be released within the acquisition context.
> > > +However, when it comes to a deadlock by folio lock that is not supposed
> > > +to be released within the acquisition context or other general
> > > +synchronization mechanisms, lockdep doesn't work.
> > > +
> > > +NOTE: In this document, 'context' refers to any type of unique context
> > > +e.g. irq context, normal process context, wq worker context, or so on.
> > > +
> > > +Can lockdep detect the following deadlock?
> > > +
> > > +.. literal::
> > > +
> > > + context X context Y context Z
> > > +
> > > + mutex_lock A
> > > + folio_lock B
> > > + folio_lock B <- DEADLOCK
> > > + mutex_lock A <- DEADLOCK
> > > + folio_unlock B
> > > + folio_unlock B
> > > + mutex_unlock A
> > > + mutex_unlock A
> > > +
> > > +No. What about the following?
> > > +
> > > +.. literal::
> > > +
> > > + context X context Y
> > > +
> > > + mutex_lock A
> > > + mutex_lock A <- DEADLOCK
> > > + wait_for_complete B <- DEADLOCK
> > > + complete B
> > > + mutex_unlock A
> > > + mutex_unlock A
> > > +
> > > +No.
> >
> > One unanswered question from my v17 review [1]: You explain in "How DEPT works"
> > section how DEPT detects deadlock in the first example (the former with three
> > contexts). Can you do the same on the second example (the latter with two
> > contexts)?
>
> Did you mean to update the document with it? I misunderstood what you
> meant but sure I will update it as [1].
Of course!
--
An old man doll... just what I always wanted! - Clara
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v18 41/42] SUNRPC: relocate struct rcu_head to the first field of struct rpc_xprt
From: Byungchul Park @ 2025-12-15 5:15 UTC (permalink / raw)
To: Jeff Layton
Cc: linux-kernel, kernel_team, torvalds, damien.lemoal, linux-ide,
adilger.kernel, linux-ext4, mingo, peterz, will, tglx, rostedt,
joel, sashal, daniel.vetter, duyuyang, johannes.berg, tj, tytso,
willy, david, amir73il, gregkh, kernel-team, linux-mm, akpm,
mhocko, minchan, hannes, vdavydov.dev, sj, jglisse, dennis, cl,
penberg, rientjes, vbabka, ngupta, linux-block, josef,
linux-fsdevel, jack, dan.j.williams, hch, djwong, dri-devel,
rodrigosiqueiramelo, melissa.srw, hamohammed.sa, harry.yoo,
chris.p.wilson, gwan-gyeong.mun, max.byungchul.park, boqun.feng,
longman, yunseong.kim, ysk, yeoreum.yun, netdev, matthew.brost,
her0gyugyu, corbet, catalin.marinas, bp, x86, hpa, luto,
sumit.semwal, gustavo, christian.koenig, andi.shyti, arnd,
lorenzo.stoakes, Liam.Howlett, rppt, surenb, mcgrof, petr.pavlu,
da.gomez, samitolvanen, paulmck, frederic, neeraj.upadhyay,
joelagnelf, josh, urezki, mathieu.desnoyers, jiangshanlai,
qiang.zhang, juri.lelli, vincent.guittot, dietmar.eggemann,
bsegall, mgorman, vschneid, chuck.lever, neil, okorniev, Dai.Ngo,
tom, trondmy, anna, kees, bigeasy, clrkwllms, mark.rutland,
ada.coupriediaz, kristina.martsenko, wangkefeng.wang, broonie,
kevin.brodsky, dwmw, shakeel.butt, ast, ziy, yuzhao, baolin.wang,
usamaarif642, joel.granados, richard.weiyang, geert+renesas,
tim.c.chen, linux, alexander.shishkin, lillian, chenhuacai,
francesco, guoweikang.kernel, link, jpoimboe, masahiroy, brauner,
thomas.weissschuh, oleg, mjguzik, andrii, wangfushuai, linux-doc,
linux-arm-kernel, linux-media, linaro-mm-sig, linux-i2c,
linux-arch, linux-modules, rcu, linux-nfs, linux-rt-devel,
2407018371, dakr, miguel.ojeda.sandonis, neilb, bagasdotme,
wsa+renesas, dave.hansen, geert, ojeda, alex.gaynor, gary,
bjorn3_gh, lossin, a.hindborg, aliceryhl, tmgross, rust-for-linux
In-Reply-To: <cd65b963dd4edade3afb2e7d27eb33af1c62682e.camel@kernel.org>
On Fri, Dec 05, 2025 at 04:27:52AM -0500, Jeff Layton wrote:
> On Fri, 2025-12-05 at 16:18 +0900, Byungchul Park wrote:
> > While compiling Linux kernel with DEPT on, the following error was
> > observed:
> >
> > ./include/linux/rcupdate.h:1084:17: note: in expansion of macro
> > ‘BUILD_BUG_ON’
> > 1084 | BUILD_BUG_ON(offsetof(typeof(*(ptr)), rhf) >= 4096); \
> > | ^~~~~~~~~~~~
> > ./include/linux/rcupdate.h:1047:29: note: in expansion of macro
> > 'kvfree_rcu_arg_2'
> > 1047 | #define kfree_rcu(ptr, rhf) kvfree_rcu_arg_2(ptr, rhf)
> > | ^~~~~~~~~~~~~~~~
> > net/sunrpc/xprt.c:1856:9: note: in expansion of macro 'kfree_rcu'
> > 1856 | kfree_rcu(xprt, rcu);
> > | ^~~~~~~~~
> > CC net/kcm/kcmproc.o
> > make[4]: *** [scripts/Makefile.build:203: net/sunrpc/xprt.o] Error 1
> >
> > Since kfree_rcu() assumes 'offset of struct rcu_head in a rcu-managed
> > struct < 4096', the offest of struct rcu_head in struct rpc_xprt should
> > not exceed 4096 but does, due to the debug information added by DEPT.
> >
> > Relocate struct rcu_head to the first field of struct rpc_xprt from an
> > arbitrary location to avoid the issue and meet the assumption.
> >
> > Reported-by: Yunseong Kim <ysk@kzalloc.com>
> > Signed-off-by: Byungchul Park <byungchul@sk.com>
> > ---
> > include/linux/sunrpc/xprt.h | 9 ++++++++-
> > 1 file changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/include/linux/sunrpc/xprt.h b/include/linux/sunrpc/xprt.h
> > index f46d1fb8f71a..666e42a17a31 100644
> > --- a/include/linux/sunrpc/xprt.h
> > +++ b/include/linux/sunrpc/xprt.h
> > @@ -211,6 +211,14 @@ enum xprt_transports {
> >
> > struct rpc_sysfs_xprt;
> > struct rpc_xprt {
> > + /*
> > + * Place struct rcu_head within the first 4096 bytes of struct
> > + * rpc_xprt if sizeof(struct rpc_xprt) > 4096, so that
> > + * kfree_rcu() can simply work assuming that. See the comment
> > + * in kfree_rcu().
> > + */
> > + struct rcu_head rcu;
> > +
> > struct kref kref; /* Reference count */
> > const struct rpc_xprt_ops *ops; /* transport methods */
> > unsigned int id; /* transport id */
> > @@ -317,7 +325,6 @@ struct rpc_xprt {
> > #if IS_ENABLED(CONFIG_SUNRPC_DEBUG)
> > struct dentry *debugfs; /* debugfs directory */
> > #endif
> > - struct rcu_head rcu;
> > const struct xprt_class *xprt_class;
> > struct rpc_sysfs_xprt *xprt_sysfs;
> > bool main; /*mark if this is the 1st transport */
>
> Seems fine to me.
>
> Reviewed-by: Jeff Layton <jlayton@kernel.org>
Thank you, Jeff.
Byungchul
^ permalink raw reply
* Re: [PATCH v18 25/42] dept: add documents for dept
From: Byungchul Park @ 2025-12-15 4:22 UTC (permalink / raw)
To: Bagas Sanjaya
Cc: linux-kernel, kernel_team, torvalds, damien.lemoal, linux-ide,
adilger.kernel, linux-ext4, mingo, peterz, will, tglx, rostedt,
joel, sashal, daniel.vetter, duyuyang, johannes.berg, tj, tytso,
willy, david, amir73il, gregkh, kernel-team, linux-mm, akpm,
mhocko, minchan, hannes, vdavydov.dev, sj, jglisse, dennis, cl,
penberg, rientjes, vbabka, ngupta, linux-block, josef,
linux-fsdevel, jack, jlayton, dan.j.williams, hch, djwong,
dri-devel, rodrigosiqueiramelo, melissa.srw, hamohammed.sa,
harry.yoo, chris.p.wilson, gwan-gyeong.mun, max.byungchul.park,
boqun.feng, longman, yunseong.kim, ysk, yeoreum.yun, netdev,
matthew.brost, her0gyugyu, corbet, catalin.marinas, bp, x86, hpa,
luto, sumit.semwal, gustavo, christian.koenig, andi.shyti, arnd,
lorenzo.stoakes, Liam.Howlett, rppt, surenb, mcgrof, petr.pavlu,
da.gomez, samitolvanen, paulmck, frederic, neeraj.upadhyay,
joelagnelf, josh, urezki, mathieu.desnoyers, jiangshanlai,
qiang.zhang, juri.lelli, vincent.guittot, dietmar.eggemann,
bsegall, mgorman, vschneid, chuck.lever, neil, okorniev, Dai.Ngo,
tom, trondmy, anna, kees, bigeasy, clrkwllms, mark.rutland,
ada.coupriediaz, kristina.martsenko, wangkefeng.wang, broonie,
kevin.brodsky, dwmw, shakeel.butt, ast, ziy, yuzhao, baolin.wang,
usamaarif642, joel.granados, richard.weiyang, geert+renesas,
tim.c.chen, linux, alexander.shishkin, lillian, chenhuacai,
francesco, guoweikang.kernel, link, jpoimboe, masahiroy, brauner,
thomas.weissschuh, oleg, mjguzik, andrii, wangfushuai, linux-doc,
linux-arm-kernel, linux-media, linaro-mm-sig, linux-i2c,
linux-arch, linux-modules, rcu, linux-nfs, linux-rt-devel,
2407018371, dakr, miguel.ojeda.sandonis, neilb, wsa+renesas,
dave.hansen, geert, ojeda, alex.gaynor, gary, bjorn3_gh, lossin,
a.hindborg, aliceryhl, tmgross, rust-for-linux
In-Reply-To: <aTN38kJjBftxnjm9@archie.me>
On Sat, Dec 06, 2025 at 07:25:22AM +0700, Bagas Sanjaya wrote:
> On Fri, Dec 05, 2025 at 04:18:38PM +0900, Byungchul Park wrote:
> > Add documents describing the concept and APIs of dept.
> >
> > Signed-off-by: Byungchul Park <byungchul@sk.com>
> > ---
> > Documentation/dev-tools/dept.rst | 778 +++++++++++++++++++++++++++
> > Documentation/dev-tools/dept_api.rst | 125 +++++
>
> You forget to add toctree entries:
I'm sorry for late reply.
Thanks a lot!
> ---- >8 ----
> diff --git a/Documentation/dev-tools/index.rst b/Documentation/dev-tools/index.rst
> index 4b8425e348abd1..02c858f5ed1fa2 100644
> --- a/Documentation/dev-tools/index.rst
> +++ b/Documentation/dev-tools/index.rst
> @@ -22,6 +22,8 @@ Documentation/process/debugging/index.rst
> clang-format
> coccinelle
> sparse
> + dept
> + dept_api
> kcov
> gcov
> kasan
>
> > +Lockdep detects a deadlock by checking lock acquisition order. For
> > +example, a graph to track acquisition order built by lockdep might look
> > +like:
> > +
> > +.. literal::
> > +
> > + A -> B -
> > + \
> > + -> E
> > + /
> > + C -> D -
> > +
> > + where 'A -> B' means that acquisition A is prior to acquisition B
> > + with A still held.
>
> Use code-block directive for literal code blocks:
I will.
> ---- >8 ----
> diff --git a/Documentation/dev-tools/dept.rst b/Documentation/dev-tools/dept.rst
> index 333166464543d7..8394c4ea81bc2a 100644
> --- a/Documentation/dev-tools/dept.rst
> +++ b/Documentation/dev-tools/dept.rst
> @@ -10,7 +10,7 @@ Lockdep detects a deadlock by checking lock acquisition order. For
> example, a graph to track acquisition order built by lockdep might look
> like:
>
> -.. literal::
> +.. code-block::
>
> A -> B -
> \
> @@ -25,7 +25,7 @@ Lockdep keeps adding each new acquisition order into the graph at
> runtime. For example, 'E -> C' will be added when the two locks have
> been acquired in the order, E and then C. The graph will look like:
>
> -.. literal::
> +.. code-block::
>
> A -> B -
> \
> @@ -41,7 +41,7 @@ been acquired in the order, E and then C. The graph will look like:
>
> This graph contains a subgraph that demonstrates a loop like:
>
> -.. literal::
> +.. code-block::
>
> -> E -
> / \
> @@ -76,7 +76,7 @@ e.g. irq context, normal process context, wq worker context, or so on.
>
> Can lockdep detect the following deadlock?
>
> -.. literal::
> +.. code-block::
>
> context X context Y context Z
>
> @@ -91,7 +91,7 @@ Can lockdep detect the following deadlock?
>
> No. What about the following?
>
> -.. literal::
> +.. code-block::
>
> context X context Y
>
> @@ -116,7 +116,7 @@ What leads a deadlock
> A deadlock occurs when one or multi contexts are waiting for events that
> will never happen. For example:
>
> -.. literal::
> +.. code-block::
>
> context X context Y context Z
>
> @@ -148,7 +148,7 @@ In terms of dependency:
>
> Dependency graph reflecting this example will look like:
>
> -.. literal::
> +.. code-block::
>
> -> C -> A -> B -
> / \
> @@ -171,7 +171,7 @@ Introduce DEPT
> DEPT(DEPendency Tracker) tracks wait and event instead of lock
> acquisition order so as to recognize the following situation:
>
> -.. literal::
> +.. code-block::
>
> context X context Y context Z
>
> @@ -186,7 +186,7 @@ acquisition order so as to recognize the following situation:
> and builds up a dependency graph at runtime that is similar to lockdep.
> The graph might look like:
>
> -.. literal::
> +.. code-block::
>
> -> C -> A -> B -
> / \
> @@ -199,7 +199,7 @@ DEPT keeps adding each new dependency into the graph at runtime. For
> example, 'B -> D' will be added when event D occurrence is a
> prerequisite to reaching event B like:
>
> -.. literal::
> +.. code-block::
>
> context W
>
> @@ -211,7 +211,7 @@ prerequisite to reaching event B like:
>
> After the addition, the graph will look like:
>
> -.. literal::
> +.. code-block::
>
> -> D
> /
> @@ -236,7 +236,7 @@ How DEPT works
> Let's take a look how DEPT works with the 1st example in the section
> 'Limitation of lockdep'.
>
> -.. literal::
> +.. code-block::
>
> context X context Y context Z
>
> @@ -256,7 +256,7 @@ event.
>
> Adding comments to describe DEPT's view in detail:
>
> -.. literal::
> +.. code-block::
>
> context X context Y context Z
>
> @@ -293,7 +293,7 @@ Adding comments to describe DEPT's view in detail:
>
> Let's build up dependency graph with this example. Firstly, context X:
>
> -.. literal::
> +.. code-block::
>
> context X
>
> @@ -304,7 +304,7 @@ Let's build up dependency graph with this example. Firstly, context X:
>
> There are no events to create dependency. Next, context Y:
>
> -.. literal::
> +.. code-block::
>
> context Y
>
> @@ -332,7 +332,7 @@ event A cannot be triggered if wait B cannot be awakened by event B.
> Therefore, we can say event A depends on event B, say, 'A -> B'. The
> graph will look like after adding the dependency:
>
> -.. literal::
> +.. code-block::
>
> A -> B
>
> @@ -340,7 +340,7 @@ graph will look like after adding the dependency:
>
> Lastly, context Z:
>
> -.. literal::
> +.. code-block::
>
> context Z
>
> @@ -362,7 +362,7 @@ triggered if wait A cannot be awakened by event A. Therefore, we can
> say event B depends on event A, say, 'B -> A'. The graph will look like
> after adding the dependency:
>
> -.. literal::
> +.. code-block::
>
> -> A -> B -
> / \
> @@ -386,7 +386,7 @@ Interpret DEPT report
>
> The following is the same example in the section 'How DEPT works'.
>
> -.. literal::
> +.. code-block::
>
> context X context Y context Z
>
> @@ -425,7 +425,7 @@ We can simplify this by labeling each waiting point with [W], each
> point where its event's context starts with [S] and each event with [E].
> This example will look like after the labeling:
>
> -.. literal::
> +.. code-block::
>
> context X context Y context Z
>
> @@ -443,7 +443,7 @@ DEPT uses the symbols [W], [S] and [E] in its report as described above.
> The following is an example reported by DEPT for a real problem in
> practice.
>
> -.. literal::
> +.. code-block::
>
> Link: https://lore.kernel.org/lkml/6383cde5-cf4b-facf-6e07-1378a485657d@I-love.SAKURA.ne.jp/#t
> Link: https://lore.kernel.org/lkml/1674268856-31807-1-git-send-email-byungchul.park@lge.com/
> @@ -646,7 +646,7 @@ practice.
>
> Let's take a look at the summary that is the most important part.
>
> -.. literal::
> +.. code-block::
>
> ---------------------------------------------------
> summary
> @@ -669,7 +669,7 @@ Let's take a look at the summary that is the most important part.
>
> The summary shows the following scenario:
>
> -.. literal::
> +.. code-block::
>
> context A context B context ?(unknown)
>
> @@ -684,7 +684,7 @@ The summary shows the following scenario:
>
> Adding comments to describe DEPT's view in detail:
>
> -.. literal::
> +.. code-block::
>
> context A context B context ?(unknown)
>
> @@ -711,7 +711,7 @@ Adding comments to describe DEPT's view in detail:
>
> Let's build up dependency graph with this report. Firstly, context A:
>
> -.. literal::
> +.. code-block::
>
> context A
>
> @@ -735,7 +735,7 @@ unlock(&ni->ni_lock:0) depends on folio_unlock(&f1), say,
>
> The graph will look like after adding the dependency:
>
> -.. literal::
> +.. code-block::
>
> unlock(&ni->ni_lock:0) -> folio_unlock(&f1)
>
> @@ -743,7 +743,7 @@ The graph will look like after adding the dependency:
>
> Secondly, context B:
>
> -.. literal::
> +.. code-block::
>
> context B
>
> @@ -762,7 +762,7 @@ folio_unlock(&f1) depends on unlock(&ni->ni_lock:0), say,
>
> The graph will look like after adding the dependency:
>
> -.. literal::
> +.. code-block::
>
> -> unlock(&ni->ni_lock:0) -> folio_unlock(&f1) -
> / \
>
> > +Limitation of lockdep
> > +---------------------
> > +
> > +Lockdep deals with a deadlock by typical lock e.g. spinlock and mutex,
> > +that are supposed to be released within the acquisition context.
> > +However, when it comes to a deadlock by folio lock that is not supposed
> > +to be released within the acquisition context or other general
> > +synchronization mechanisms, lockdep doesn't work.
> > +
> > +NOTE: In this document, 'context' refers to any type of unique context
> > +e.g. irq context, normal process context, wq worker context, or so on.
> > +
> > +Can lockdep detect the following deadlock?
> > +
> > +.. literal::
> > +
> > + context X context Y context Z
> > +
> > + mutex_lock A
> > + folio_lock B
> > + folio_lock B <- DEADLOCK
> > + mutex_lock A <- DEADLOCK
> > + folio_unlock B
> > + folio_unlock B
> > + mutex_unlock A
> > + mutex_unlock A
> > +
> > +No. What about the following?
> > +
> > +.. literal::
> > +
> > + context X context Y
> > +
> > + mutex_lock A
> > + mutex_lock A <- DEADLOCK
> > + wait_for_complete B <- DEADLOCK
> > + complete B
> > + mutex_unlock A
> > + mutex_unlock A
> > +
> > +No.
>
> One unanswered question from my v17 review [1]: You explain in "How DEPT works"
> section how DEPT detects deadlock in the first example (the former with three
> contexts). Can you do the same on the second example (the latter with two
> contexts)?
Did you mean to update the document with it? I misunderstood what you
meant but sure I will update it as [1].
[1] https://lore.kernel.org/linux-doc/20251013012855.GB52546@system.software.com/
Thanks.
Byungchul
> Thanks.
>
> [1]: https://lore.kernel.org/linux-doc/aN84jKyrE1BumpLj@archie.me/
>
> --
> An old man doll... just what I always wanted! - Clara
^ permalink raw reply
* [syzbot] [mm?] INFO: rcu detected stall in finish_dput
From: syzbot @ 2025-12-15 4:03 UTC (permalink / raw)
To: atomlin, da.gomez, linux-kernel, linux-mm, linux-modules, mcgrof,
petr.pavlu, samitolvanen, syzkaller-bugs
Hello,
syzbot found the following issue on:
HEAD commit: 8f0b4cce4481 Linux 6.19-rc1
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=119d511a580000
kernel config: https://syzkaller.appspot.com/x/.config?x=a94030c847137a18
dashboard link: https://syzkaller.appspot.com/bug?extid=d1b2c58262854b97eb1f
compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=10d38d92580000
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/2b5022055115/disk-8f0b4cce.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/17c3669e328d/vmlinux-8f0b4cce.xz
kernel image: https://storage.googleapis.com/syzbot-assets/7e72b5dbef4f/bzImage-8f0b4cce.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+d1b2c58262854b97eb1f@syzkaller.appspotmail.com
rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
rcu: Tasks blocked on level-0 rcu_node (CPUs 0-1): P6163/1:b..l
rcu: (detected by 1, t=10502 jiffies, g=13717, q=383 ncpus=2)
task:syz.2.19 state:R running task stack:26480 pid:6163 tgid:6163 ppid:5961 task_flags:0x40004c flags:0x00080001
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5256 [inline]
__schedule+0x14bc/0x5000 kernel/sched/core.c:6863
preempt_schedule_irq+0xb5/0x150 kernel/sched/core.c:7190
irqentry_exit+0x5d8/0x660 kernel/entry/common.c:216
asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:697
RIP: 0010:lock_release+0x2bb/0x3b0 kernel/locking/lockdep.c:5893
Code: 00 00 75 52 f7 c3 00 02 00 00 74 01 fb 65 48 8b 05 da 07 e0 10 48 3b 44 24 28 75 75 48 83 c4 30 5b 41 5c 41 5d 41 5e 41 5f 5d <e9> ab 98 71 ff cc 90 0f 0b 90 e9 70 fd ff ff 90 0f 0b 90 48 c7 c7
RSP: 0018:ffffc90003b8efd8 EFLAGS: 00000282
RAX: 670f1dcbf9e62d00 RBX: ffffffff81ac174d RCX: 670f1dcbf9e62d00
RDX: 0000000000000000 RSI: ffffffff8d978ed0 RDI: ffffffff8bc08360
RBP: 0000000000000000 R08: ffffffff81ac174d R09: ffffffff8df419e0
R10: dffffc0000000000 R11: ffffffff81ada000 R12: ffff888029131e80
R13: 1ffff92000771e38 R14: 00007f810118f749 R15: 1ffff92000771e16
rcu_lock_release include/linux/rcupdate.h:341 [inline]
rcu_read_unlock include/linux/rcupdate.h:897 [inline]
class_rcu_destructor include/linux/rcupdate.h:1195 [inline]
is_module_text_address+0x18b/0x1e0 kernel/module/main.c:3858
kernel_text_address+0x94/0xe0 kernel/extable.c:119
__kernel_text_address+0xd/0x40 kernel/extable.c:79
unwind_get_return_address+0x4d/0x90 arch/x86/kernel/unwind_orc.c:369
arch_stack_walk+0xfc/0x150 arch/x86/kernel/stacktrace.c:26
stack_trace_save+0x9c/0xe0 kernel/stacktrace.c:122
save_stack+0xf5/0x1f0 mm/page_owner.c:165
__reset_page_owner+0x71/0x1f0 mm/page_owner.c:320
reset_page_owner include/linux/page_owner.h:25 [inline]
free_pages_prepare mm/page_alloc.c:1395 [inline]
free_unref_folios+0xdb3/0x14f0 mm/page_alloc.c:3000
folios_put_refs+0x584/0x670 mm/swap.c:1002
folio_batch_release include/linux/pagevec.h:101 [inline]
shmem_undo_range+0x49e/0x1490 mm/shmem.c:1137
shmem_truncate_range mm/shmem.c:1249 [inline]
shmem_evict_inode+0x26e/0xa70 mm/shmem.c:1379
evict+0x5f4/0xae0 fs/inode.c:837
__dentry_kill+0x209/0x660 fs/dcache.c:670
finish_dput+0xc9/0x480 fs/dcache.c:879
__fput+0x68e/0xa70 fs/file_table.c:476
task_work_run+0x1d4/0x260 kernel/task_work.c:233
exit_task_work include/linux/task_work.h:40 [inline]
do_exit+0x6c5/0x2310 kernel/exit.c:971
do_group_exit+0x21c/0x2d0 kernel/exit.c:1112
__do_sys_exit_group kernel/exit.c:1123 [inline]
__se_sys_exit_group kernel/exit.c:1121 [inline]
__x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1121
x64_sys_call+0x2210/0x2210 arch/x86/include/generated/asm/syscalls_64.h:232
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xfa/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f810118f749
RSP: 002b:00007ffdda280538 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f810118f749
RDX: 0000000000000064 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 0000000000000003 R08: 0000000bda28062f R09: 00007f81013b4280
R10: 0000000000000001 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f81013b4280 R14: 0000000000000003 R15: 00007ffdda2805f0
</TASK>
rcu: rcu_preempt kthread starved for 10546 jiffies! g13717 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=0
rcu: Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior.
rcu: RCU grace-period kthread stack dump:
task:rcu_preempt state:R running task stack:27128 pid:16 tgid:16 ppid:2 task_flags:0x208040 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5256 [inline]
__schedule+0x14bc/0x5000 kernel/sched/core.c:6863
__schedule_loop kernel/sched/core.c:6945 [inline]
schedule+0x165/0x360 kernel/sched/core.c:6960
schedule_timeout+0x12b/0x270 kernel/time/sleep_timeout.c:99
rcu_gp_fqs_loop+0x301/0x1540 kernel/rcu/tree.c:2083
rcu_gp_kthread+0x99/0x390 kernel/rcu/tree.c:2285
kthread+0x711/0x8a0 kernel/kthread.c:463
ret_from_fork+0x599/0xb30 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246
</TASK>
rcu: Stack dump where RCU GP kthread last ran:
Sending NMI from CPU 1 to CPUs 0:
NMI backtrace for cpu 0
CPU: 0 UID: 0 PID: 6168 Comm: syz.0.25 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025
RIP: 0010:rdtsc_ordered arch/x86/include/asm/tsc.h:57 [inline]
RIP: 0010:read_tsc+0xc/0x20 arch/x86/kernel/tsc.c:1135
Code: e9 e8 fe ff ff e8 e4 c7 f2 09 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa e8 e7 c7 58 00 0f 01 f9 <66> 90 48 c1 e2 20 48 09 d0 e9 e1 57 a7 ff cc 0f 1f 44 00 00 90 90
RSP: 0000:ffffc90003077ac0 EFLAGS: 00000093
RAX: 0000000063ea710f RBX: ffffffff8dd73ac0 RCX: 0000000000000000
RDX: 000000000000008f RSI: 0000000000000000 RDI: ffffffff8dd73ac0
RBP: 000000000000b122 R08: ffffffff81af6795 R09: ffffffff998e3508
R10: 0000000000000003 R11: ffffffff8168e910 R12: 000000399661b39b
R13: dffffc0000000000 R14: 00000039b4a1e637 R15: dffffc0000000000
FS: 00007fd54d67f6c0(0000) GS:ffff888125e35000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00002000000001c0 CR3: 0000000033588000 CR4: 0000000000350ef0
Call Trace:
<TASK>
tk_clock_read kernel/time/timekeeping.c:295 [inline]
timekeeping_get_ns kernel/time/timekeeping.c:404 [inline]
ktime_get+0x97/0x200 kernel/time/timekeeping.c:826
clockevents_program_event+0xe8/0x350 kernel/time/clockevents.c:326
hrtimer_start_range_ns+0xd8a/0x1080 kernel/time/hrtimer.c:1323
__posixtimer_deliver_signal kernel/time/posix-timers.c:321 [inline]
posixtimer_deliver_signal+0x1cf/0x410 kernel/time/posix-timers.c:347
dequeue_signal+0x24a/0x370 kernel/signal.c:660
get_signal+0x55e/0x1340 kernel/signal.c:2914
arch_do_signal_or_restart+0x9a/0x7a0 arch/x86/kernel/signal.c:337
__exit_to_user_mode_loop kernel/entry/common.c:41 [inline]
exit_to_user_mode_loop kernel/entry/common.c:75 [inline]
__exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline]
irqentry_exit_to_user_mode_prepare include/linux/irq-entry-common.h:270 [inline]
irqentry_exit_to_user_mode include/linux/irq-entry-common.h:339 [inline]
irqentry_exit+0x177/0x660 kernel/entry/common.c:196
asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:697
RIP: 0033:0x7fd54c78f747
Code: ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 <0f> 05 48 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89
RSP: 002b:00007fd54d67f0e8 EFLAGS: 00000246
RAX: 00000000000000ca RBX: 00007fd54c9e5fa8 RCX: 00007fd54c78f749
RDX: 0000000000000000 RSI: 0000000000000080 RDI: 00007fd54c9e5fa8
RBP: 00007fd54c9e5fa0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fd54c9e6038 R14: 00007ffeebd71e40 R15: 00007ffeebd71f28
</TASK>
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title
If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.
If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)
If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report
If you want to undo deduplication, reply with:
#syz undup
^ permalink raw reply
* Re: [PATCH] modules: moduleparam.h: add kernel-doc comments
From: Randy Dunlap @ 2025-12-14 20:26 UTC (permalink / raw)
To: linux-kernel; +Cc: Luis Chamberlain, Petr Pavlu, Daniel Gomez, linux-modules
In-Reply-To: <20251214202600.2212699-1-rdunlap@infradead.org>
Sorry. Accidental resend. Please disregard it.
^ permalink raw reply
* [PATCH] modules: moduleparam.h: add kernel-doc comments
From: Randy Dunlap @ 2025-12-14 20:26 UTC (permalink / raw)
To: linux-kernel
Cc: Randy Dunlap, Luis Chamberlain, Petr Pavlu, Daniel Gomez,
linux-modules
Add missing kernel-doc comments to prevent kernel-doc warnings:
Warning: include/linux/moduleparam.h:364 function parameter 'arg' not
described in '__core_param_cb'
Warning: include/linux/moduleparam.h:395 No description found for return
value of 'parameq'
Warning: include/linux/moduleparam.h:405 No description found for return
value of 'parameqn'
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
---
Cc: Luis Chamberlain <mcgrof@kernel.org>
Cc: Petr Pavlu <petr.pavlu@suse.com>
Cc: Daniel Gomez <da.gomez@kernel.org>
Cc: linux-modules@vger.kernel.org
---
include/linux/moduleparam.h | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
--- linux-next-20251203.orig/include/linux/moduleparam.h
+++ linux-next-20251203/include/linux/moduleparam.h
@@ -355,8 +355,8 @@ static inline void kernel_param_unlock(s
/**
* __core_param_cb - similar like core_param, with a set/get ops instead of type.
* @name: the name of the cmdline and sysfs parameter (often the same as var)
- * @var: the variable
* @ops: the set & get operations for this parameter.
+ * @arg: the variable
* @perm: visibility in sysfs
*
* Ideally this should be called 'core_param_cb', but the name has been
@@ -390,7 +390,7 @@ static inline void kernel_param_unlock(s
* @name1: parameter name 1
* @name2: parameter name 2
*
- * Returns true if the two parameter names are equal.
+ * Returns: true if the two parameter names are equal.
* Dashes (-) are considered equal to underscores (_).
*/
extern bool parameq(const char *name1, const char *name2);
@@ -402,6 +402,10 @@ extern bool parameq(const char *name1, c
* @n: the length to compare
*
* Similar to parameq(), except it compares @n characters.
+ *
+ * Returns: true if the first @n characters of the two parameter names
+ * are equal.
+ * Dashes (-) are considered equal to underscores (_).
*/
extern bool parameqn(const char *name1, const char *name2, size_t n);
^ permalink raw reply
* [PATCH] modules: moduleparam.h: add kernel-doc comments
From: Randy Dunlap @ 2025-12-14 20:23 UTC (permalink / raw)
To: linux-kernel
Cc: Randy Dunlap, Luis Chamberlain, Petr Pavlu, Daniel Gomez,
linux-modules
Add missing kernel-doc comments to prevent kernel-doc warnings:
Warning: include/linux/moduleparam.h:364 function parameter 'arg' not
described in '__core_param_cb'
Warning: include/linux/moduleparam.h:395 No description found for return
value of 'parameq'
Warning: include/linux/moduleparam.h:405 No description found for return
value of 'parameqn'
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
---
Cc: Luis Chamberlain <mcgrof@kernel.org>
Cc: Petr Pavlu <petr.pavlu@suse.com>
Cc: Daniel Gomez <da.gomez@kernel.org>
Cc: linux-modules@vger.kernel.org
---
include/linux/moduleparam.h | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
--- linux-next-20251203.orig/include/linux/moduleparam.h
+++ linux-next-20251203/include/linux/moduleparam.h
@@ -355,8 +355,8 @@ static inline void kernel_param_unlock(s
/**
* __core_param_cb - similar like core_param, with a set/get ops instead of type.
* @name: the name of the cmdline and sysfs parameter (often the same as var)
- * @var: the variable
* @ops: the set & get operations for this parameter.
+ * @arg: the variable
* @perm: visibility in sysfs
*
* Ideally this should be called 'core_param_cb', but the name has been
@@ -390,7 +390,7 @@ static inline void kernel_param_unlock(s
* @name1: parameter name 1
* @name2: parameter name 2
*
- * Returns true if the two parameter names are equal.
+ * Returns: true if the two parameter names are equal.
* Dashes (-) are considered equal to underscores (_).
*/
extern bool parameq(const char *name1, const char *name2);
@@ -402,6 +402,10 @@ extern bool parameq(const char *name1, c
* @n: the length to compare
*
* Similar to parameq(), except it compares @n characters.
+ *
+ * Returns: true if the first @n characters of the two parameter names
+ * are equal.
+ * Dashes (-) are considered equal to underscores (_).
*/
extern bool parameqn(const char *name1, const char *name2, size_t n);
^ permalink raw reply
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