From: Steven Rostedt <rostedt@goodmis.org>
To: Jens Axboe <axboe@kernel.dk>
Cc: Jiazi Li <jqqlijiazi@gmail.com>,
linux-kernel@vger.kernel.org,
"peixuan.qiu" <peixuan.qiu@transsion.com>,
io-uring@vger.kernel.org, Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH] stacktrace: do not trace user stack for user_worker tasks
Date: Wed, 25 Jun 2025 16:50:54 -0400 [thread overview]
Message-ID: <20250625165054.199093f1@batman.local.home> (raw)
In-Reply-To: <80e637d3-482d-4f3a-9a86-948d3837b24d@kernel.dk>
[
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!
]
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.
>
> > 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.
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.
-- Steve
next prev parent reply other threads:[~2025-06-25 20:51 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20250623115914.12076-1-jqqlijiazi@gmail.com>
2025-06-24 17:07 ` [PATCH] stacktrace: do not trace user stack for user_worker tasks Steven Rostedt
2025-06-25 10:00 ` Jiazi Li
2025-06-25 16:23 ` Jens Axboe
2025-06-25 20:50 ` Steven Rostedt [this message]
2025-06-25 22:30 ` Jens Axboe
2025-06-25 22:41 ` Steven Rostedt
2025-06-25 23:54 ` Keith Busch
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250625165054.199093f1@batman.local.home \
--to=rostedt@goodmis.org \
--cc=axboe@kernel.dk \
--cc=io-uring@vger.kernel.org \
--cc=jqqlijiazi@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=peixuan.qiu@transsion.com \
--cc=peterz@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox