On Sat, 26 Apr 2025 20:42:21 +0200
Ingo Molnar <[email protected]> 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
