linux-kernel - Re: [PATCH] sched/core: Introduce task_*() helpers for PF

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

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

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

Message-ID: <20250426160630.46108366@gandalf.local.home>
Date: Sat, 26 Apr 2025 16:06:30 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Ingo Molnar <mingo@...nel.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>, linux-kernel@...r.kernel.org,
 linux-trace-kernel@...r.kernel.org, Masami Hiramatsu <mhiramat@...nel.org>,
 Mark Rutland <mark.rutland@....com>, Mathieu Desnoyers
 <mathieu.desnoyers@...icios.com>, Peter Zijlstra <peterz@...radead.org>,
 Linus Torvalds <torvalds@...ux-foundation.org>, Ingo Molnar
 <mingo@...hat.com>, x86@...nel.org, Kees Cook <kees@...nel.org>,
 bpf@...r.kernel.org, Tejun Heo <tj@...nel.org>, Julia Lawall
 <Julia.Lawall@...ia.fr>, Nicolas Palix <nicolas.palix@...g.fr>,
 cocci@...ia.fr, "H. Peter Anvin" <hpa@...or.com>, Thomas Gleixner
 <tglx@...utronix.de>
Subject: Re: [PATCH] sched/core: Introduce task_*() helpers for PF_ flags

On Sat, 26 Apr 2025 20:42:21 +0200
Ingo Molnar <mingo@...nel.org> wrote:

> > kernel/sched/core.c:    if (!curr->mm || (curr->flags & (PF_EXITING | PF_KTHREAD)) ||
> > kernel/sched/fair.c:    if (!curr->mm || (curr->flags & (PF_EXITING | PF_KTHREAD)) || work->next != work)
> > kernel/trace/bpf_trace.c:                    current->flags & (PF_KTHREAD | PF_EXITING)))
> > kernel/trace/bpf_trace.c:       if (unlikely(task->flags & (PF_KTHREAD | PF_EXITING)))
> > 
> > Maybe we can have a: is_user_exiting_or_kthread() ?  
> 
> No, we don't need is_user_exiting_or_kthread(). At all. Ever. In this 
> universe. Or in any alternative universes. We don't even need 
> is_user_exiting_or_kthread() in horror fiction novels written for 
> kernel developers: there's really a limit to the level of horror that 
> people are able to accept. Sheesh ...

Ingo,

A simple "No we do not need that" would suffice. This isn't 2005 anymore,
where we come up with creative ways to insult each other. We're better now.

> And no, we don't need separate helpers for !task_kthread() et al: the C 
> logical negation unary operator is perfectly readable when placed 
> before a function call or a macro invocation, and a competent Linux 
> kernel developer is expected to recognize it on sight:
> 
> 	if (!task_kthread(task))
> 		...

Not really. I originally tried just having a single "is_kernel_thread()"
where I would use the "!is_kernel_thread()" for user thread, but honestly,
it wasn't much better than the "!(task->flags & PF_KTHREAD)".

And just because it's not a kernel thread, does it mean it will always be a
user space thread? Could it one day also be a guest thread (if we decide to
have such a thing)?

Wanting to know if something is a user space thread, "if (!task_kthread(task))"
seems short sighted. As it assumes that we only have two types of threads.
It may be true today, but may not be the case in the future.

	if (!task_kthread(task))

Still takes a second more to understand that's a user space thread than:

	if (task_user(task))

would.

-- Steve