Since the task->comm is guaranteed to be NUL-ternimated, we can print it
directly. Add a new vsnprintf format specifier "%pTN" to print task
comm,
where 'p' represents the task Pointer, 'T' stands for Task, and
'N' denots
Name. With this abstraction, the user no longer needs to care about
retrieving task name.
checkpatch.pl is updated accordingly.
Link:
https://lore.kernel.org/bpf/CAHk-=wgqrwFXK-CO8-V4fwUh5ymnUZ=wJnFyufV1dM9rC1t3Lg
at mail.gmail.com
Suggested-by: Linus Torvalds <torvalds at linux-foundation.org>
Signed-off-by: Yafang Shao <laoar.shao at gmail.com>
Cc: Andrew Morton <akpm at linux-foundation.org>
Cc: Petr Mladek <pmladek at suse.com>
Cc: Steven Rostedt <rostedt at goodmis.org>
Cc: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
Cc: Rasmus Villemoes <linux at rasmusvillemoes.dk>
Cc: Sergey Senozhatsky <senozhatsky at chromium.org>
Cc: Andy Whitcroft <apw at canonical.com>
Cc: Joe Perches <joe at perches.com>
Cc: Dwaipayan Ray <dwaipayanray1 at gmail.com>
Cc: Lukas Bulwahn <lukas.bulwahn at gmail.com>
---
lib/vsprintf.c | 18 ++++++++++++++++++
scripts/checkpatch.pl | 6 ++++--
2 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 6ac02bbb7df1..bb1018d79655 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -2273,6 +2273,17 @@ char *resource_or_range(const char *fmt, char *buf, char
*end, void *ptr,
return resource_string(buf, end, ptr, spec, fmt);
}
+static noinline_for_stack
+char *task_name_string(char *buf, char *end, struct task_struct *p,
+ struct printf_spec spec)
+{
+ if (check_pointer(&buf, end, p, spec))
+ return buf;
+
+ buf = string(buf, end, p->comm, spec);
+ return buf;
+}
+
int __init no_hash_pointers_enable(char *str)
{
if (no_hash_pointers)
@@ -2525,6 +2536,13 @@ char *pointer(const char *fmt, char *buf, char *end, void
*ptr,
default:
return error_string(buf, end, "(einval)", spec);
}
+ case 'T':
+ switch (fmt[1]) {
+ case 'N':
+ return task_name_string(buf, end, ptr, spec);
+ default:
+ return error_string(buf, end, "(einval)", spec);
+ }
default:
return default_pointer(buf, end, ptr, spec);
}
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 9eed3683ad76..fe0d80f55ce8 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -6908,11 +6908,13 @@ sub process {
$specifier = $1;
$extension = $2;
$qualifier = $3;
- if ($extension !~ /[4SsBKRraEehMmIiUDdgVCbGNOxtf]/ ||
+ if ($extension !~ /[4SsBKRraEehMmIiUDdgVCbGNOxtfT]/ ||
($extension eq "f" &&
defined $qualifier && $qualifier !~ /^w/) ||
($extension eq "4" &&
- defined $qualifier && $qualifier !~ /^cc/)) {
+ defined $qualifier && $qualifier !~ /^cc/) ||
+ ($extension eq "T" &&
+ defined $qualifier && $qualifier ne "N")) {
$bad_specifier = $specifier;
last;
}
--
2.43.5
On Fri 2024-12-13 13:46:04, Yafang Shao wrote:> Since the task->comm is guaranteed to be NUL-ternimated, we can print it > directly. Add a new vsnprintf format specifier "%pTN" to print task comm, > where 'p' represents the task Pointer, 'T' stands for Task, and 'N' denots > Name. With this abstraction, the user no longer needs to care about > retrieving task name.What is the advantage, please? Honestly, I believe that the meaning of printk("%s\n", task->comm); is much more clear than using a cryptic %pXYZ modifier: printk("%pTN\n", task); The %pXYZ modifiers makes sense only when the formatting of the printed information needs some processing. But this is a plain string. IMHO, it is not worth it. In fact, I believe that it is a counter productive. Best Regards, Petr
Petr Mladek <pmladek at suse.com> writes:> On Fri 2024-12-13 13:46:04, Yafang Shao wrote: >> Since the task->comm is guaranteed to be NUL-ternimated, we can print it >> directly. Add a new vsnprintf format specifier "%pTN" to print task comm, >> where 'p' represents the task Pointer, 'T' stands for Task, and 'N' denots >> Name. With this abstraction, the user no longer needs to care about >> retrieving task name. > > What is the advantage, please? > > Honestly, I believe that the meaning of > > printk("%s\n", task->comm); > > is much more clear than using a cryptic %pXYZ modifier: > > printk("%pTN\n", task); > > > The %pXYZ modifiers makes sense only when the formatting of the printed > information needs some processing. But this is a plain string. > IMHO, it is not worth it. In fact, I believe that it is a > counter productive.I agree, it makes the code harder to read for someone who is not familiar with all the %p magic we have (like me). -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
On Fri, Dec 13, 2024 at 4:05?PM Petr Mladek <pmladek at suse.com> wrote:> > On Fri 2024-12-13 13:46:04, Yafang Shao wrote: > > Since the task->comm is guaranteed to be NUL-ternimated, we can print it > > directly. Add a new vsnprintf format specifier "%pTN" to print task comm, > > where 'p' represents the task Pointer, 'T' stands for Task, and 'N' denots > > Name. With this abstraction, the user no longer needs to care about > > retrieving task name. > > What is the advantage, please?The advantage is that it provides the flexibility to modify the comm representation to meet future requirements. For instance, we could rename it to "task_name" and increase its size.> > Honestly, I believe that the meaning of > > printk("%s\n", task->comm); > > is much more clear than using a cryptic %pXYZ modifier: > > printk("%pTN\n", task); > > > The %pXYZ modifiers makes sense only when the formatting of the printed > information needs some processing. But this is a plain string.That makes sense to me.> IMHO, it is not worth it. In fact, I believe that it is a > counter productive.Linus, what are your thoughts? -- Regards Yafang