From: Namhyung Kim <namhyung@kernel.org>
To: Ilya Leoshkevich <iii@linux.ibm.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>,
linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org,
Heiko Carstens <hca@linux.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Alexander Gordeev <agordeev@linux.ibm.com>
Subject: Re: [PATCH 1/5] perf jitdump: Fix PID namespace detection
Date: Fri, 14 Nov 2025 00:07:48 -0800 [thread overview]
Message-ID: <aRbjVG3q2kCOl8BJ@google.com> (raw)
In-Reply-To: <b02b6c7a1fcea87248a60ee9c94aaa6e078316d0.camel@linux.ibm.com>
Hello,
Sorry for the delay.
On Fri, Nov 07, 2025 at 09:19:47AM +0100, Ilya Leoshkevich wrote:
> On Thu, 2025-11-06 at 18:16 -0800, Namhyung Kim wrote:
> > On Wed, Nov 05, 2025 at 08:10:24PM +0100, Ilya Leoshkevich wrote:
> > > perf inject fails to detect jitdump file produced by a process
> > > running in a different PID namespace if this process has not exited
> > > yet.
> > >
> > > The PID namespace heuristic in jit_detect() compares two PIDs:
> > >
> > > * pid: outermost NStgid of mmap(jitdump) caller from perf's PoV.
> > > * nsinfo__nstgid(nsi): innermost NStgid of mmap(jitdump) caller
> > > from
> > > perf's PoV.
> > >
> > > The semantics of the in_pidns variable can be seen in, e.g.,
> > > nsinfo__get_nspid(): it's true if and only if perf and the profiled
> > > process are in different PID namespaces.
> > >
> > > The current logic is clearly inverted: if pid and
> > > nsinfo__nstgid(nsi)
> > > are different, then the profiled process must be in a different PID
> > > namespace. This, of course, ignores that fact that they may end up
> > > being equal by accident, but that's not the point here.
> > >
> > > Fix by flipping the comparison.
> > >
> > > Changing just that, however, breaks the case when the process has
> > > exited. Add explicit support for that by adding "synthesized" field
> > > to
> > > nsinfo, which tracks whether NStgid was obtained from a running
> > > process (ignoring considerations of PID reuse or running inject on
> > > a different machine). When the namespace information is
> > > synthesized,
> > > assume the process ran in a different PID namespace.
> >
> > I'm not sure I'm following. It'd be great if anyone understand the
> > topic well could review.
>
> Perhaps some data from the testcase from [5/5] can make it more clear.
> Here are the PIDs that exist in reality:
>
> unshare[a] perf-record unshare[b] jshell
> Host PIDNS: 1000 1001 1002 1003
> PIDNS[a]: - 1 2 3
> PIDNS[b]: - - - 1
>
> In jit_detect() we deal with 2 of them.
>
> - pid is jshell@PIDNS[a].
> It is taken from the MMAP2 event, this is how perf sees jshell.
>
> - pid2 is jshell@PIDNS[b].
> It is taken from "jit-1.dump", this is how jshell sees itself.
>
> - nsinfo__nstgid(nsi) ideally should be jshell@PIDNS[b].
> This is jshell's innermost NStgid.
> But perf can see it differently. This is the core of the problem this
> series deals with.
Thanks a lot for the example and explanation! I'm trying to understand.
:)
>
> Why does nsinfo__nstgid(nsi) vary? Because the kernel does not record
> it, and perf has to guess it. I have a WIP patch to fix that [1], but
> it needs a lot more work at this point.
>
> How does perf guess it? It looks into /proc/$PID/status. This is quite
> unreliable, but this is the best perf can do under circumstances. As a
> result we have 3 possibilities:
>
> - The original process is still around. This is the buggy case. In this
> case nsinfo__nstgid(nsi) == jshell@PIDNS[b]. IMHO this is a very
> clear indication of namespacing, and that's why the condition should
> be flipped.
So perf would look at /proc/3/status and the file would have the below
NStgid: 1003 3 1
and *in_pidns should be true, right?
>
> - The original process has exited and PID was not reused. I believe
> this is the use case the current code has been extensively tested
> with. In this case perf assumes there was no namespacing and
> nsinfo__nstgid(nsi) == pid. That's why I need the "synthesized"
> field: to indicate that NStgid is just an assumption and didn't come
> from any real data source.
Ok, can you please put short comments on each boolean field so that we
can see the meaning of them clearly?
>
> - The original process has exited ans PID was reused. I am not trying
> to deal with this here, because this is rare and absolutely anything
> is possible. The only concern is running perf inject on a different
> machine, but I'm also not sure whether we should care about this.
Fair enough.
Thanks,
Namhyung
>
> [1]
> https://github.com/iii-i/linux/commit/4b519b774eed850abe0757df39be13a704d2748e
>
> [...]
>
> > > diff --git a/tools/perf/util/namespaces.h
> > > b/tools/perf/util/namespaces.h
> > > index e95c79b80e27c..41ba2ea8137e5 100644
> > > --- a/tools/perf/util/namespaces.h
> > > +++ b/tools/perf/util/namespaces.h
> > > @@ -38,6 +38,7 @@ DECLARE_RC_STRUCT(nsinfo) {
> > > bool in_pidns;
> > > char *mntns_path;
> > > refcount_t refcnt;
> > > + bool synthesized;
> >
> > It'd be nice if you can put this along with other bool fields.
>
> Sure, will do.
>
> [...]
> >
next prev parent reply other threads:[~2025-11-14 8:07 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-05 19:10 [PATCH 0/5] perf jitdump: Fix PID namespace detection Ilya Leoshkevich
2025-11-05 19:10 ` [PATCH 1/5] " Ilya Leoshkevich
2025-11-07 2:16 ` Namhyung Kim
2025-11-07 8:19 ` Ilya Leoshkevich
2025-11-14 8:07 ` Namhyung Kim [this message]
2025-11-14 12:44 ` Ilya Leoshkevich
2025-11-14 18:44 ` Namhyung Kim
2025-11-05 19:10 ` [PATCH 2/5] perf test java symbol: Get rid of shellcheck warnings Ilya Leoshkevich
2025-11-07 2:07 ` Namhyung Kim
2025-11-07 7:57 ` Ilya Leoshkevich
2025-11-05 19:10 ` [PATCH 3/5] perf test java symbol: Extract LIBJVMTI detection Ilya Leoshkevich
2025-11-05 19:10 ` [PATCH 4/5] perf test java symbol: Fix a false negative in symbol regex Ilya Leoshkevich
2025-11-07 2:08 ` Namhyung Kim
2025-11-07 7:59 ` Ilya Leoshkevich
2025-11-05 19:10 ` [PATCH 5/5] perf test java symbol: Add PID namespace variant Ilya Leoshkevich
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=aRbjVG3q2kCOl8BJ@google.com \
--to=namhyung@kernel.org \
--cc=acme@kernel.org \
--cc=agordeev@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=iii@linux.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.