linux-kernel - Re: [PATCH v11 03/11] perf: Use current->flags & 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250626101115.3e6b99bf@gandalf.local.home>
Date: Thu, 26 Jun 2025 10:11:15 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Jens Axboe <axboe@...nel.dk>
Cc: linux-kernel@...r.kernel.org, linux-trace-kernel@...r.kernel.org,
 bpf@...r.kernel.org, x86@...nel.org, Masami Hiramatsu
 <mhiramat@...nel.org>, Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
 Josh Poimboeuf <jpoimboe@...nel.org>, Peter Zijlstra
 <peterz@...radead.org>, Ingo Molnar <mingo@...nel.org>, Jiri Olsa
 <jolsa@...nel.org>, Namhyung Kim <namhyung@...nel.org>, Thomas Gleixner
 <tglx@...utronix.de>, Andrii Nakryiko <andrii@...nel.org>, Indu Bhagat
 <indu.bhagat@...cle.com>, "Jose E. Marchesi" <jemarch@....org>, Beau
 Belgrave <beaub@...ux.microsoft.com>, Jens Remus <jremus@...ux.ibm.com>,
 Linus Torvalds <torvalds@...ux-foundation.org>, Andrew Morton
 <akpm@...ux-foundation.org>
Subject: Re: [PATCH v11 03/11] perf: Use current->flags & PF_KTHREAD instead
 of current->mm == NULL

On Thu, 26 Jun 2025 07:48:40 -0600
Jens Axboe <axboe@...nel.dk> wrote:

> On 6/25/25 5:15 PM, Steven Rostedt wrote:
> > From: Steven Rostedt <rostedt@...dmis.org>
> > 
> > To determine if a task is a kernel thread or not, it is more reliable to
> > use (current->flags & PF_KTHREAD) than to rely on current->mm being NULL.
> > That is because some kernel tasks (io_uring helpers) may have a mm field.  
> 
> This commit message is very odd, imho, and wrong. To check if it's a
> kernel thread yes you should use PF_KTHREAD, but that has nothing to do

Yeah, I figured this was wrong when I saw your reply in the other thread.
That's why I Cc'd you on this.

[
  For those interested in what that other thread is:
  https://lore.kernel.org/all/20250624130744.602c5b5f@batman.local.home/
]

> with PF_USER_WORKER. In fact, as mentioned in a previous reply,
> current->mm may be non-NULL for a kthread as well, if it's done
> kthread_use_mm().
> 
> If the current check for "is kernel thread" was using ->mm to gauge
> then, then the current check was just wrong, period.

Yes, but unfortunately, that was a way a task was checked to see if it was
a kernel thread or not. Which was right "most of the time". But it's wrong
to use that, because it can be wrong "some of the time" :-p

Which brings us to this discussion.

I believe Peter was under the assumption that we should not use current->mm
to see if it's a user task or not, and use PF_KTHREAD instead. But for
perf, a user task is something that will return back to user space, as the
idea is to profile the user space stack trace.

You said that PF_USER_WORKER never came from user space, so from the perf
point of view, it *is* a kernel thread, and we don't want to treat it as a
user space one. If we check current->mm to be a user space task, or if we
check for PF_KTHREAD to be a kernel task, we are wrong in both cases when
it comes to a task marked as PF_USER_WORKER.

This brings up having a function like "is_kernel_thread()" (or remove the
'is' if people don't like that) that returns true if the task *only* runs
in the kernel.

-- Steve