From: Steven Rostedt <rostedt@goodmis.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.

Link: https://lore.kernel.org/linux-trace-kernel/20250424163607.GE18306@noisy.programming.kicks-ass.net/

Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
---
 kernel/events/callchain.c | 6 +++---
 kernel/events/core.c      | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/kernel/events/callchain.c b/kernel/events/callchain.c
index cd0e3fc7ed05..42d21761cb4d 100644
--- a/kernel/events/callchain.c
+++ b/kernel/events/callchain.c
@@ -246,10 +246,10 @@ get_perf_callchain(struct pt_regs *regs, bool kernel, bool user,
 
 	if (user && !crosstask) {
 		if (!user_mode(regs)) {
-			if  (current->mm)
-				regs = task_pt_regs(current);
-			else
+			if (current->flags & PF_KTHREAD)
 				regs = NULL;
+			else
+				regs = task_pt_regs(current);
 		}
 
 		if (regs) {
diff --git a/kernel/events/core.c b/kernel/events/core.c
index ca7e9e7d19bf..ae371007a2a6 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -8054,7 +8054,7 @@ static u64 perf_virt_to_phys(u64 virt)
 		 * Try IRQ-safe get_user_page_fast_only first.
 		 * If failed, leave phys_addr as 0.
 		 */
-		if (current->mm != NULL) {
+		if (!(current->flags & PF_KTHREAD)) {
 			struct page *p;
 
 			pagefault_disable();
-- 
2.47.2

On 6/25/25 5:15 PM, Steven Rostedt wrote:
> From: Steven Rostedt <rostedt@goodmis.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
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.

-- 
Jens Axboe

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

> On 6/25/25 5:15 PM, Steven Rostedt wrote:
> > From: Steven Rostedt <rostedt@goodmis.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