Re: [PATCH] stacktrace: do not trace user stack for user_worker tasks

[Steven Rostedt <rostedt@goodmis.org>]

On Wed, 25 Jun 2025 16:30:55 -0600
Jens Axboe <axboe@kernel.dk> wrote:

> On 6/25/25 2:50 PM, Steven Rostedt wrote:
> > [
> >   Adding Peter Zijlstra as he has been telling me to test against
> >   PF_KTHREAD instead of current->mm to tell if it is a kernel thread.
> >   But that seems to not be enough!
> > ]  
> 
> Not sure I follow - if current->mm is NULL, then it's PF_KTHREAD too.
> Unless it's used kthread_use_mm().
> 
> PF_USER_WORKER will have current->mm of the user task that it was cloned
> from.

The suggestion was to use (current->flags & PF_KTHREAD) instead of
!current->mm to determine if a task is a kernel thread or not as we don't
want to do user space stack tracing on kernel threads. Peter said that
because of io threads which have current->mm set, you can't rely on that,
so check the PF_KHTREAD flag instead. This was assuming that io kthreads
had that set too, but apparently it does not and we need to check for
PF_USER_WORKER instead of just PF_KTHREAD.

> 
> > On Wed, 25 Jun 2025 10:23:28 -0600
> > Jens Axboe <axboe@kernel.dk> wrote:
> >   
> >> On 6/24/25 11:07 AM, Steven Rostedt wrote:  
> >>> On Mon, 23 Jun 2025 19:59:11 +0800
> >>> Jiazi Li <jqqlijiazi@gmail.com> wrote:
> >>>     
> >>>> Tasks with PF_USER_WORKER flag also only run in kernel space,
> >>>> so do not trace user stack for these tasks.    
> >>>
> >>> What exactly is the difference between PF_KTHREAD and PF_USER_WORKER?    
> >>
> >> One is a kernel thread (eg no mm, etc), the other is basically a user
> >> thread. None of them exit to userspace, that's basically the only
> >> thing they have in common.  
> > 
> > Was it ever in user space? Because exiting isn't the issue for getting
> > a user space stack. If it never was in user space than sure, there's no
> > reason to look at the user space stack.  
> 
> It was never in userspace.

OK then for user space stack tracing it is the same as a KTHREAD.

> 
> >>> Has all the locations that test for PF_KTHREAD been audited to make
> >>> sure that PF_USER_WORKER isn't also needed?    
> >>
> >> I did when adding it, to the best of my knowledge. But there certainly
> >> could still be gaps. Sometimes not easy to see why code checks for
> >> PF_KTHREAD in the first place.
> >>  
> >>> I'm working on other code that needs to differentiate between user
> >>> tasks and kernel tasks, and having to have multiple flags to test is
> >>> becoming quite a burden.    
> >>
> >> None of them are user tasks, but PF_USER_WORKER does look like a
> >> user thread and acts like one, except it wasn't created by eg
> >> pthread_create() and it never returns to userspace. When it's done,
> >> it's simply reaped.
> >>  
> > 
> > I'm assuming that it also never was in user space, which is where we
> > don't want to do any user space stack trace.  
> 
> It was not.
> 
> > This looks like more rationale for having a kernel_task() user_task()
> > helper functions:
> > 
> >   https://lore.kernel.org/linux-trace-kernel/20250425204120.639530125@goodmis.org/
> > 
> > Where one returns true for both PF_KERNEL and PF_USER_WORKER and the
> > other returns false.  
> 
> On vacation right now, but you can just CC me on the next iteration and
> I'll take a look.
> 

Well, it was sortof NACKED by Ingo, and he started another version, but I
don't know if that is still happening or not.

  https://lore.kernel.org/linux-trace-kernel/aA0pDUDQViCA1hwi@gmail.com/

Although, that patch just looks like its simply adding helper functions for
all the pf flags, but doesn't solve the issue of just testing "Is this a
kernel thread or user thread?"

-- Steve