kernel/linux.git/tools/perf/util/jitdump.c, branch v6.19.11

perf jitdump: Fix missed dso__put

2025-12-03T19:07:46+00:00

Reference count checking caught a missing dso__put following a machine__findnew_dso_id. Signed-off-by: Ian Rogers Reviewed-by: Arnaldo Carvalho de Melo Signed-off-by: Namhyung Kim

perf: replace strcpy() with strncpy() in util/jitdump.c

2025-11-20T19:13:04+00:00

Usage of strcpy() can lead to buffer overflows. Therefore, it has been replaced with strncpy(). The output file path is provided as a parameter and might be restricted by command-line by default. But this defensive patch will prevent any potential overflow, making the code more robust against future changes in input handling. Testing: - ran perf test from tools/perf and did not observe any regression with the earlier code Signed-off-by: Hrishikesh Suresh Signed-off-by: Namhyung Kim

perf jitdump: Directly mark the jitdump DSO

2025-07-25T17:37:56+00:00

The DSO being generated was being accessed through a thread's maps, this is unnecessary as the dso can just be directly found. This avoids problems with passing a NULL evsel which may be inspected to determine properties of a callchain when using the buildid DSO marking code. Signed-off-by: Ian Rogers Link: https://lore.kernel.org/r/20250724163302.596743-8-irogers@google.com Signed-off-by: Namhyung Kim

perf sample: Make user_regs and intr_regs optional

2025-02-13T04:06:11+00:00

The struct dump_regs contains 512 bytes of cache_regs, meaning the two values in perf_sample contribute 1088 bytes of its total 1384 bytes size. Initializing this much memory has a cost reported by Tavian Barnes as about 2.5% when running `perf script --itrace=i0`: https://lore.kernel.org/lkml/d841b97b3ad2ca8bcab07e4293375fb7c32dfce7.1736618095.git.tavianator@tavianator.com/ Adrian Hunter replied that the zero initialization was necessary and couldn't simply be removed. This patch aims to strike a middle ground of still zeroing the perf_sample, but removing 79% of its size by make user_regs and intr_regs optional pointers to zalloc-ed memory. To support the allocation accessors are created for user_regs and intr_regs. To support correct cleanup perf_sample__init and perf_sample__exit functions are created and added throughout the code base. Signed-off-by: Ian Rogers Link: https://lore.kernel.org/r/20250113194345.1537821-1-irogers@google.com Signed-off-by: Namhyung Kim

perf jitdump: Fixup in_pidns member when java agent and 'perf record' are not in the same pidns

2025-01-08T20:30:50+00:00

When running 'perf record' outside a container and the java agent inside a container the jit_repipe_code_load() and friends will emit PERF_RECORD_MMAP2 entries for the jitdump records and will check if we need to fixup the pid/tid: nspid = jr->load.pid; pid = jr_entry_pid(jd, jr); tid = jr_entry_tid(jd, jr); The jr_entry_pid() function looks if we're in the same pidns: static pid_t jr_entry_pid(struct jit_buf_desc *jd, union jr_entry *jr) { if (jd->nsi && nsinfo__in_pidns(jd->nsi)) return nsinfo__tgid(jd->nsi); return jr->load.pid; } But since the thread, populated from perf.data records, try to figure out if in the same pidns by actually trying, on the system where 'perf inject' is running to open a procfs file (a bug that remains to be fixed), assuming that if it is not possible that is because that thread terminated and thus we can't get its namespace info and tolerates nsinfo__init() failing, noting only that that namespace can't be entered, so don't even try. But we can kinda get at least that info (thread->nsinfo->in_pidns) from the data in the perf.data file, namely the pid and tid in the PERF_RECORD_MMAP2 for the jit-.dump file generated from the java agent, if the PERF_RECORD_MMAP2->pid is the same as what is in the jitdump file, then we're in the same namespace, otherwise we need to use the PERF_RECORD_MMAP2->pid. This all has to be revamped for this jitdump + running perf from outside, as the meaning of in_pidns is being abused, the initialization of nsinfo->pid with the value coming from the PERF_RECORD_MMAP2 data is wrong as it is the pid _outside_ the container since perf was running there. The hack in this patch at least produces the expected result in this scenario by following the assumptions in the current codebase for finding maps and for generating the PERF_RECORD_MMAP2 for the ELF files synthesized from the jitdump records in jit_repipe_code_load(), etc.s Reported-by: Francesco Nigro Reported-by: Ilan Green Cc: Adrian Hunter Cc: Clark Williams Cc: Ian Rogers Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Kan Liang Cc: Namhyung Kim Cc: Stephane Eranian Cc: Thomas Gleixner Cc: Yonatan Goldschmidt Link: https://lore.kernel.org/r/20241206204828.507527-5-acme@kernel.org Signed-off-by: Arnaldo Carvalho de Melo

perf jitdump: Accept jitdump mmaps emitted from inside containers

2025-01-08T20:29:51+00:00

When the java agent is running inside a container it will emit mmaps with the format: ⬢ [acme@toolbox a]$ perf report -D | grep PERF_RECORD_MMAP | grep \.dump 0 0x15c400 [0x90]: PERF_RECORD_MMAP2 3308868/3308868: [0x7fb8de6cb000(0x1000) @ 0 08:14 3222905945 0]: r-xp /tmp/.debug/jit/java-jit-20241126.XXTxEIOn/jit-1.dump ⬢ [acme@toolbox a]$ Since perf is running from outside the container it sees the pid 3308868 in PERF_RECORD_MMAP2, while the agent saw the pid of the profiled app inside the container, 1. The previous validation was: if (pid && pid2 != nsinfo__nstgid(nsi)) pid2 at this point is '1' (/jit-1.dump), so it considers this as a malformed jitdump mmap and refuses to process it. The test ends up as: if (3308868 && 1 != 3308868) which is true and the jitdump is not processed. Since 1 in the container namespace is really 3308868 in the namespace that perf is running, consider this a valid mmap. We need to make perf realize this and behave accordingly, for now checking instead: if (pid && pid2 && pid != nsinfo__nstgid(nsi)) Translating to: if (3308868 && 1 && 3308868 != 3308868) Will make the jitdump mmap to be considered valid and processed. The jitdump is described in: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/perf/Documentation/jitdump-specification.txt Now we end up with the expected flurry of MMAPs, one per jitted function transformed into a little ELF file that should then be processable by the other perf features, like code annotation: [acme@toolbox a]$ echo $JITDUMPDIR /tmp/.debug/jit [acme@toolbox a]$ First use 'perf inject': ⬢ [acme@toolbox a]$ time perf inject -i perf.data -o acme-perf-injected.data -j Then look at the PERF_RECORD_MMAP events in the result file, that went thru the JIT map file: ⬢ [acme@toolbox a]$ ls -la /tmp/*.map -rw-r--r--. 1 acme acme 2989559 Nov 27 16:11 /tmp/perf-3308868.map [acme@toolbox a]$ It is a symbol table: ⬢ [acme@toolbox a]$ head /tmp/*.map 0x00007fb8bda5c1a0 0x00000000000000d0 java.lang.String java.lang.module.ModuleDescriptor.name() 0x00007fb8bda5c4a0 0x0000000000000178 int java.lang.StringLatin1.hashCode(byte[]) 0x00007fb8bda5c9a0 0x00000000000000d0 java.lang.String org.springframework.boot.context.config.ConfigDataLocation.getValue() 0x00007fb8bda5cca0 0x00000000000000d0 java.lang.module.ModuleDescriptor java.lang.module.ModuleReference.descriptor() 0x00007fb8bda5cfa0 0x00000000000000d0 java.lang.Object java.util.KeyValueHolder.getKey() 0x00007fb8bda5d2a0 0x00000000000000d0 java.lang.Object java.util.KeyValueHolder.getValue() 0x00007fb8bda5d5a0 0x0000000000000218 boolean jdk.internal.misc.Unsafe.compareAndSetReference(java.lang.Object, long, java.lang.Object, java.lang.Object) 0x00007fb8bda5d9a0 0x00000000000001f0 boolean jdk.internal.misc.Unsafe.compareAndSetLong(java.lang.Object, long, long, long) 0x00007fb8bda5dda0 0x00000000000001f8 void java.lang.System.arraycopy(java.lang.Object, int, java.lang.Object, int, int) 0x00007fb8bda5e1a0 0x00000000000001e8 int java.lang.Object.hashCode() ⬢ [acme@toolbox a]$ As specified in: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/perf/Documentation/jit-interface.txt This was collected from inside the container, so came as /tmp/perf-1.map. To make perf, running outside the container to use it we need to copy it to /tmp/perf-3308868.map. This is another logic that has to be added to perf to work on this scenario of running outside the container but processing things created by the hava agent running inside the container. With all this in place we get to: ⬢ [acme@toolbox a]$ perf report -D -i acme-perf-injected.data | \ grep PERF_RECORD_MMAP > /tmp/acme-perf-injected.data.mmaps ; \ wc -l /tmp/acme-perf-injected.data.mmaps 44182 /tmp/acme-perf-injected.data.mmaps ⬢ [acme@toolbox a]$ tail /tmp/acme-perf-injected.data.mmaps 1030266786574466 0x7bc9e0 [0x98]: PERF_RECORD_MMAP2 1/78: [0x7fb8c0ceb1c0(0x8d0) @ 0x80 00:2c 238715 1]: --xs /tmp/.debug/jit/java-jit-20241126.XXTxEIOn/jitted-1-43989.so 1030266795288774 0x7bca78 [0x98]: PERF_RECORD_MMAP2 1/78: [0x7fb8c0cecc00(0x7e8) @ 0x80 00:2c 238716 1]: --xs /tmp/.debug/jit/java-jit-20241126.XXTxEIOn/jitted-1-43990.so 1030266895967339 0x7bcb10 [0x98]: PERF_RECORD_MMAP2 1/78: [0x7fb8c0cee500(0x3328) @ 0x80 00:2c 238717 1]: --xs /tmp/.debug/jit/java-jit-20241126.XXTxEIOn/jitted-1-43991.so 1030266915748306 0x7bcba8 [0x98]: PERF_RECORD_MMAP2 1/78: [0x7fb8c0aae0a0(0x138) @ 0x80 00:2c 238718 1]: --xs /tmp/.debug/jit/java-jit-20241126.XXTxEIOn/jitted-1-43992.so 1030267185851220 0x7bcc40 [0x98]: PERF_RECORD_MMAP2 1/78: [0x7fb8c0cf61e0(0x3b50) @ 0x80 00:2c 238719 1]: --xs /tmp/.debug/jit/java-jit-20241126.XXTxEIOn/jitted-1-43993.so 1030267231364524 0x7bccd8 [0x98]: PERF_RECORD_MMAP2 1/78: [0x7fb8c0cfea80(0x14a0) @ 0x80 00:2c 238720 1]: --xs /tmp/.debug/jit/java-jit-20241126.XXTxEIOn/jitted-1-43994.so 1030267425498831 0x7bcd70 [0x98]: PERF_RECORD_MMAP2 1/78: [0x7fb8c054b4a0(0x338) @ 0x80 00:2c 238721 1]: --xs /tmp/.debug/jit/java-jit-20241126.XXTxEIOn/jitted-1-43995.so 1030267506147888 0x7bce08 [0x98]: PERF_RECORD_MMAP2 1/78: [0x7fb8c0a995c0(0x1e8) @ 0x80 00:2c 238722 1]: --xs /tmp/.debug/jit/java-jit-20241126.XXTxEIOn/jitted-1-43996.so 1030268112586116 0x7bcea0 [0x98]: PERF_RECORD_MMAP2 1/78: [0x7fb8c0d02520(0x258) @ 0x80 00:2c 238723 1]: --xs /tmp/.debug/jit/java-jit-20241126.XXTxEIOn/jitted-1-43997.so 1030269435398150 0x7bcf38 [0x98]: PERF_RECORD_MMAP2 1/78: [0x7fb8c0d02dc0(0x278) @ 0x80 00:2c 238724 1]: --xs /tmp/.debug/jit/java-jit-20241126.XXTxEIOn/jitted-1-43998.so ⬢ [acme@toolbox a]$ And if we look at those tiny ELF files generated by the jitdump code used by 'perf inject' we see: ⬢ [acme@toolbox a]$ file /tmp/.debug/jit/java-jit-20241126.XXTxEIOn/jitted-1-43989.so /tmp/.debug/jit/java-jit-20241126.XXTxEIOn/jitted-1-43989.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), statically linked, BuildID[sha1]=790591db95a77d644657dfe5058658b200000000, with debug_info, not stripped ⬢ [acme@toolbox a]$ file /tmp/.debug/jit/java-jit-20241126.XXTxEIOn/jitted-1-43990.so /tmp/.debug/jit/java-jit-20241126.XXTxEIOn/jitted-1-43990.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), statically linked, BuildID[sha1]=762f932acbee53a22638bf4c2b86780200000000, with debug_info, not stripped ⬢ [acme@toolbox a]$ ⬢ [acme@toolbox a]$ ls -la /tmp/.debug/jit/java-jit-20241126.XXTxEIOn/jitted-1-43989.so /tmp/.debug/jit/java-jit-20241126.XXTxEIOn/jitted-1-43990.so -rw-r--r--. 1 acme acme 9432 Nov 29 10:56 /tmp/.debug/jit/java-jit-20241126.XXTxEIOn/jitted-1-43989.so -rw-r--r--. 1 acme acme 7504 Nov 29 10:56 /tmp/.debug/jit/java-jit-20241126.XXTxEIOn/jitted-1-43990.so ⬢ [acme@toolbox a]$ And: ⬢ [acme@toolbox a]$ objdump -dS /tmp/.debug/jit/java-jit-20241126.XXTxEIOn/jitted-1-43990.so | head -20 /tmp/.debug/jit/java-jit-20241126.XXTxEIOn/jitted-1-43990.so: file format elf64-x86-64 Disassembly of section .text: 0000000000000080 : 80: 44 8b 56 08 mov 0x8(%rsi),%r10d 84: 49 c1 e2 03 shl $0x3,%r10 88: 49 3b c2 cmp %r10,%rax 8b: 0f 85 6f 15 83 fc jne fffffffffc831600 91: 66 66 90 data16 xchg %ax,%ax 94: 0f 1f 84 00 00 00 00 nopl 0x0(%rax,%rax,1) 9b: 00 9c: 66 66 66 90 data16 data16 xchg %ax,%ax a0: 89 84 24 00 c0 fe ff mov %eax,-0x14000(%rsp) a7: 55 push %rbp a8: 48 8b ec mov %rsp,%rbp ab: 48 83 ec 40 sub $0x40,%rsp af: 48 89 34 24 mov %rsi,(%rsp) ⬢ [acme@toolbox a]$ The thing now being investigated is why we can't annotate anything here, maybe that JITDUMPDIR is getting in the way: ⬢ [acme@toolbox a]$ perf annotate --stdio2 -i acme-perf-injected.data 'java.lang.String com.fasterxml.jackson.core.sym.CharsToNameCanonicalizer.findSymbol(char[], int, int, int)' Error: Couldn't annotate java.lang.String com.fasterxml.jackson.core.sym.CharsToNameCanonicalizer.findSymbol(char[], int, int, int): Internal error: Invalid -1 error code ⬢ [acme@toolbox a]$ In the tests I performed while merging this patch: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6d518ac7be6223811ab947897273b1bbef846180 It works, but then there was no JITDUMPDIR involved: /home/acme/.debug/jit/java-jit-20241127.XXF1SRgN/jitted-3912413-4191.so ⬢ [acme@toolbox perf-tools-next]$ perf report --call-graph none --no-child -i perf-injected.data | grep jitted- | head 1.36% java jitted-3912413-54.so [.] Interpreter 0.30% C1 CompilerThre jitted-3912413-1.so [.] flush_icache_stub 0.18% java jitted-3912413-4184.so [.] org.apache.fop.fo.properties.PropertyMaker.get(int, org.apache.fop.fo.PropertyList, boolean, boolean) 0.18% java jitted-3912413-4177.so [.] org.apache.fop.layoutmgr.inline.TextLayoutManager.getNextKnuthElements(org.apache.fop.layoutmgr.LayoutContext, int) 0.13% java jitted-3912413-3845.so [.] java.text.DecimalFormat.subformatNumber(java.lang.StringBuffer, java.text.Format$FieldDelegate, boolean, boolean, int, int, int, int) 0.11% java jitted-3912413-4191.so [.] org.apache.fop.fo.FObj.addChildNode(org.apache.fop.fo.FONode) 0.09% java jitted-3912413-2418.so [.] org.apache.fop.fo.XMLWhiteSpaceHandler.handleWhiteSpace() 0.08% Reference Handl jitted-3912413-54.so [.] Interpreter 0.08% java jitted-3912413-3326.so [.] org.apache.xmlgraphics.fonts.Glyphs.stringToGlyph(java.lang.String) 0.08% java jitted-3912413-3953.so [.] org.apache.fop.layoutmgr.BreakingAlgorithm.considerLegalBreak(org.apache.fop.layoutmgr.KnuthElement, int) ⬢ [acme@toolbox perf-tools-next]$ And then: ⬢ [acme@toolbox perf-tools-next]$ perf annotate --stdio2 -i perf-injected.data 'org.apache.fop.layoutmgr.inline.TextLayoutManager.getNextKnuthElements(org.apache.fop.layoutmgr.LayoutContext, int)' | head -20 Samples: 8 of event 'cpu_atom/cycles/Pu', 4000 Hz, Event count (approx.): 8112794, [percent: local period] org.apache.fop.layoutmgr.inline.TextLayoutManager.getNextKnuthElements(org.apache.fop.layoutmgr.LayoutContext, int)() /home/acme/.debug/jit/java-jit-20241127.XXF1SRgN/jitted-3912413-4177.so Percent 0x80 : nop movl 0x8(%rsi),%r10d cmpl 0x8(%rax),%r10d → jne 0 movl %eax,-0x14000(%rsp) pushq %rbp subq $0xb0,%rsp nop cmpl $0x3,0x20(%r15) ↓ jne 7037 2e: movl %ecx,0x28(%rsp) movq %rdx,%rbp movl 0x64(%rdx),%ebx cmpb $0x0,0x38(%r15) ↓ jne 3a44 movq %rsi,0x30(%rsp) 48: movq 0x30(%rsp),%r10 ⬢ [acme@toolbox perf-tools-next]$ No source code nor line numbers, that I saw in another build of perf for RHEL9, for the same workload described in the cset above (a publicly available java benchmark), so something to investigate on perf upstream running on fedora, maybe some quirk with the jdk used when building perf for RHEL 9 and for Fedora 40. A related patch that should have make this all work is: "perf inject jit: Add namespaces support" https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=67dec926931448d688efb5fe34f7b5a22470fc0a But we still need to polish this some more, maybe there are differences in the agent used in NodeJS with --perf-prof and the jvmti one we're using. Hopefully describing all the steps while we investigate this case will help us improve perf support for profiling JITed environments running in containers while profiling from inside and outside it. Reported-by: Francesco Nigro Reported-by: Ilan Green Cc: Adrian Hunter Cc: Clark Williams Cc: Ian Rogers Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Kan Liang Cc: Namhyung Kim Cc: Stephane Eranian Cc: Thomas Gleixner Cc: Yonatan Goldschmidt Link: https://lore.kernel.org/r/20241206204828.507527-3-acme@kernel.org Signed-off-by: Arnaldo Carvalho de Melo

perf jit: Constify filename argument

2024-08-19T17:51:46+00:00

Make it clearer the argument is just being used as a string. Signed-off-by: Ian Rogers Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Anne Macedo Cc: Arnd Bergmann Cc: Athira Rajeev Cc: Casey Chen Cc: Chaitanya S Prakash Cc: Colin Ian King Cc: Dominique Martinet Cc: Ingo Molnar Cc: James Clark Cc: Jann Horn Cc: Jiri Olsa Cc: Kan Liang Cc: Mark Rutland Cc: Masahiro Yamada Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Sun Haiyong Cc: Weilin Wang Cc: Yang Jihong Cc: Yunseong Kim Cc: Ze Gao Link: https://lore.kernel.org/r/20240817064442.2152089-4-irogers@google.com Signed-off-by: Arnaldo Carvalho de Melo

perf tool: Constify tool pointers

2024-08-12T21:05:14+00:00

The tool pointer (to a struct largely of function pointers) is passed around but is unchanged except at initialization. Change parameter and variable types to be const to lower the possibilities of what could happen with a tool. Reviewed-by: Adrian Hunter Signed-off-by: Ian Rogers Tested-by: Adrian Hunter Tested-by: Leo Yan Cc: Alexander Shishkin Cc: Anshuman Khandual Cc: Athira Rajeev Cc: Huacai Chen Cc: Ilkka Koskinen Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: John Garry Cc: Jonathan Cameron Cc: Kan Liang Cc: Leo Yan Cc: Mark Rutland Cc: Mike Leach Cc: Namhyung Kim Cc: Nick Desaulniers Cc: Nick Terrell Cc: Oliver Upton Cc: Peter Zijlstra Cc: Song Liu Cc: Sun Haiyong Cc: Suzuki Poulouse Cc: Will Deacon Cc: Yanteng Si Cc: Yicong Yang Cc: linux-arm-kernel@lists.infradead.org Link: https://lore.kernel.org/r/20240812204720.631678-4-irogers@google.com Signed-off-by: Arnaldo Carvalho de Melo

perf jitdump: Avoid memory leak

2023-10-12T17:01:56+00:00

jit_repipe_unwinding_info is called in a loop by jit_process_dump, avoid leaking unwinding_data by free-ing before overwriting. Error detected by clang-tidy. Signed-off-by: Ian Rogers Acked-by: Namhyung Kim Cc: Ravi Bangoria Cc: Nick Desaulniers Cc: Yang Jihong Cc: Huacai Chen Cc: Nathan Chancellor Cc: Kan Liang Cc: llvm@lists.linux.dev Cc: Ming Wang Cc: Tom Rix Cc: bpf@vger.kernel.org Link: https://lore.kernel.org/r/20231009183920.200859-9-irogers@google.com Signed-off-by: Namhyung Kim

perf jit: Fix two thread leaks

2023-06-12T18:57:54+00:00

As reported by leak sanitizer with reference count checking. Signed-off-by: Ian Rogers Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ali Saidi Cc: Andi Kleen Cc: Athira Rajeev Cc: Brian Robbins Cc: Changbin Du Cc: Dmitrii Dolgov <9erthalion6@gmail.com> Cc: Fangrui Song Cc: German Gomez Cc: Ingo Molnar Cc: Ivan Babrou Cc: James Clark Cc: Jing Zhang Cc: Jiri Olsa Cc: John Garry Cc: K Prateek Nayak Cc: Kan Liang Cc: Leo Yan Cc: Liam Howlett Cc: Mark Rutland Cc: Miguel Ojeda Cc: Mike Leach Cc: Namhyung Kim Cc: Naveen N. Rao Cc: Peter Zijlstra Cc: Ravi Bangoria Cc: Sean Christopherson Cc: Steinar H. Gunderson Cc: Suzuki Poulouse Cc: Wenyu Liu Cc: Will Deacon Cc: Yang Jihong Cc: Ye Xingchen Cc: Yuan Can Cc: coresight@lists.linaro.org Cc: linux-arm-kernel@lists.infradead.org Link: https://lore.kernel.org/r/20230608232823.4027869-16-irogers@google.com Signed-off-by: Arnaldo Carvalho de Melo