From nobody Sat Sep 26 07:14:43 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8F1E94ADD8A; Thu, 3 Sep 2026 13:23:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788441792; cv=none; b=jlSBUXtLG2JA9kl8nyygTv/589vP58kXd6gMClxf0SzMJiSPOjsiADJxRfyfiRHou+CEdFsVGZXtgSM/HpxKmx/isqka6SnjIon4P9dd8XmOY8/EaB9X5dGG5ePrErOZ880yGnyEPtV0ptpg4s2WQDQ7IwEdKH/nHygvNotrGMA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788441792; c=relaxed/simple; bh=WU7m4HlKW3kdHtsYh/Q0n1wYe988EY4t+zrtpzwPc+Q=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=uFO3TyzVQ5V59FYuqkDVVc6G3iPEf3QmRPqsTKzUHex5sgdBLYsbnAkauFbY9hBm03U11G/5XXSSXa8WN776Q2dUTyzompEb4936Hd3Sk6Qnqm8+TzvPJiaKk8ALnRr2XLs1mnW7DhXjgS35HfDI8+CTB+Q4godDfrhj2pIGInE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Rye1m5FQ; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Rye1m5FQ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DE4AE1F00A3E; Thu, 3 Sep 2026 13:22:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788441780; bh=EHKFKHJ3yJDXjG8mIdYl0n+9u/+CfaZfUFzjPOjHdgs=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=Rye1m5FQZCLFWGFlFrvpqOnI5JnRuZmtqUcXSbYKkQbcAhUWWQvo18uVH3q9Gwcp8 JYc1K25ZDqpIgE30u2bD25rJJJo0nyFe1xXVPORx3p2ycJkxD9UDTh0REJeZn/Vn9u tUCVB6kIPgbalfsL2epFaIkMX211AtHUdcr6tLIbmrgy9XfmlUyPZdVkIKeDiVeU3e g3eB/eHMUyvnYCKozebCVlhr5+kH4ZMN35VWwK8EZNIK1LXUqHAOJFt6B+E36a/t6q UtBYSUHmGAMaLBe0AAsfGYVvjGH40a1wFX3r6peYrBOm2o6xkU5sKu3YAaluFc88LT vbes8ReXZfIdg== From: Arnaldo Carvalho de Melo To: Namhyung Kim Cc: Ingo Molnar , Thomas Gleixner , James Clark , Jiri Olsa , Ian Rogers , Adrian Hunter , Clark Williams , linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, Arnaldo Carvalho de Melo , sashiko-bot , Stephane Eranian Subject: [PATCH 1/5] perf jitdump: Byte-swap debug entries via unaligned-safe accessors Date: Thu, 3 Sep 2026 10:22:47 -0300 Message-ID: <20260903132251.237029-2-acme@kernel.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260903132251.237029-1-acme@kernel.org> References: <20260903132251.237029-1-acme@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Arnaldo Carvalho de Melo debug_entry records are packed with a variable-length name[] field, so entries after the first may start at addresses that are not naturally aligned for their u64 addr and int lineno/discrim fields. On strict alignment architectures the byte-swap loop in jit_get_next_entry() performed misaligned 64-bit loads and stores through struct member access, which is undefined behavior. Use get_unaligned()/put_unaligned() for the byte-swap of each field. Reported-by: sashiko-bot Cc: Stephane Eranian Assisted-by: LLM Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/util/jitdump.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/tools/perf/util/jitdump.c b/tools/perf/util/jitdump.c index d25a9fe9b020ce87..e0d5cc9a828189a2 100644 --- a/tools/perf/util/jitdump.c +++ b/tools/perf/util/jitdump.c @@ -14,6 +14,8 @@ #include #include #include +#include +#include =20 #include "event.h" #include "debug.h" @@ -343,9 +345,14 @@ jit_get_next_entry(struct jit_buf_desc *jd) /* name must be NUL-terminated within the record */ if (!memchr(ent->name, '\0', (char *)end - ent->name)) break; - ent->addr =3D bswap_64(ent->addr); - ent->lineno =3D bswap_32(ent->lineno); - ent->discrim =3D bswap_32(ent->discrim); + /* + * debug entries are packed with a variable-length + * name[], so entries after the first may be + * unaligned: byte-swap via unaligned-safe accessors. + */ + put_unaligned(bswap_64(get_unaligned(&ent->addr)), &ent->addr); + put_unaligned(bswap_32(get_unaligned(&ent->lineno)), &ent->lineno); + put_unaligned(bswap_32(get_unaligned(&ent->discrim)), &ent->discrim); ent =3D debug_entry_next(ent); } /* clamp so downstream consumers don't overrun */ --=20 2.55.0 From nobody Sat Sep 26 07:14:43 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 26C3A4AF689; Thu, 3 Sep 2026 13:23:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788441810; cv=none; b=ZbK60XsmnDpTZM6ilOkLvjqZPkzB3fuanDP0RMlgvnEVHRrGxsEF0CzXnIfxgmFnMewOQAQ9ZgJbwm0h8xJSZZ06r+K+zG4i3lIQpCxiZWqo+lMYoBeF3hgOYS1wf1gxRMoDbv9ja5gUqkMz72Y/8rtebnoe61SsNYxONqdH1Qw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788441810; c=relaxed/simple; bh=WFKa63Oye/qzhW5yXboZ0JcjgEMNPlheCI6NJqbhZPQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=YxxsBHduu6W0W3DiJsxeSal8rKxWGGF3rRHjIL5iEWy90WR3By7wcZhUo2oFsHOWmo2mboza7dK3L9qnT9peq46WsZT6WoVQnOaRdS+9T9adICFVblLMgjuUrs7AG4hCgg9Vq4pFO/QRs+kZrE3QxR6quF/Mr4EgAxiHifwvA3c= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Af1cZmvU; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Af1cZmvU" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 09C061F00A3F; Thu, 3 Sep 2026 13:23:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788441783; bh=mAt1qOAED3Xw3rcZh2N4iU/Xy6Foh+T0CCopd5eDx7s=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=Af1cZmvUMAs7AQlH+uRuj7JUuDgsM2knQwabc5NubnzpQybtUdYQDrvNTP7K/sFyX uGuPiRDdZeuXqR/TipfLhn/aLV2l5/TBp5iqLCVT1YZgzQV4i94JZcaxFQ5eek1SqB OSBIkmdjeGkZC9ETO6oJJw21q7yLslOGvV7+75268wDqpHqNR7wPG7S3tSLVWINGYB Uu0GP2/wSJiGpj9MgKyuffR4Iht4ecadkiqn6toxYDzyXvzgQZTewq4p32A/eo+TmH 19EiPk7b02RkY1pXpWJqHUHZRTY5cpf8iMoPi1qMf3hLJ1Pyyip8VvXNbml/LK7OBZ CtYpmKZqCQn4w== From: Arnaldo Carvalho de Melo To: Namhyung Kim Cc: Ingo Molnar , Thomas Gleixner , James Clark , Jiri Olsa , Ian Rogers , Adrian Hunter , Clark Williams , linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, Arnaldo Carvalho de Melo , sashiko-bot , Stephane Eranian Subject: [PATCH 2/5] perf genelf: Use unaligned-safe accessors for debug entries Date: Thu, 3 Sep 2026 10:22:48 -0300 Message-ID: <20260903132251.237029-3-acme@kernel.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260903132251.237029-1-acme@kernel.org> References: <20260903132251.237029-1-acme@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Arnaldo Carvalho de Melo debug_entry records are packed with a variable-length name[] field, so entries after the first may start at addresses that are not naturally aligned. jit_process_debug_info(), get_special_opcode() and emit_lineno_info() read and write the u64 addr and int lineno fields through struct member access, which is undefined behavior on strict-alignment architectures. Use get_unaligned()/put_unaligned() to read and update each field, matching the layout the jitdump writers (LLVM, JVM agents) emit, which packs entries without padding. Reported-by: sashiko-bot Cc: Stephane Eranian Assisted-by: LLM Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/util/genelf_debug.c | 30 ++++++++++++++++++------------ 1 file changed, 18 insertions(+), 12 deletions(-) diff --git a/tools/perf/util/genelf_debug.c b/tools/perf/util/genelf_debug.c index 8588b3e35e008396..8244d3c64103b6be 100644 --- a/tools/perf/util/genelf_debug.c +++ b/tools/perf/util/genelf_debug.c @@ -12,6 +12,8 @@ */ #include #include +#include +#include #include #include #include @@ -303,11 +305,13 @@ static ubyte get_special_opcode(struct debug_entry *e= nt, { unsigned int temp; unsigned long delta_addr; + unsigned int lineno =3D get_unaligned(&ent->lineno); + uint64_t addr =3D get_unaligned(&ent->addr); =20 /* * delta from line_base */ - temp =3D (ent->lineno - last_line) - default_debug_line_header.line_base; + temp =3D (lineno - last_line) - default_debug_line_header.line_base; =20 if (temp >=3D default_debug_line_header.line_range) return 0; @@ -315,7 +319,7 @@ static ubyte get_special_opcode(struct debug_entry *ent, /* * delta of addresses */ - delta_addr =3D (ent->addr - last_vma) / default_debug_line_header.minimum= _instruction_length; + delta_addr =3D (addr - last_vma) / default_debug_line_header.minimum_inst= ruction_length; =20 /* This is not sufficient to ensure opcode will be in [0-256] but * sufficient to ensure when summing with the delta lineno we will @@ -355,13 +359,15 @@ static void emit_lineno_info(struct buffer_ext *be, unsigned long last_vma =3D 0; char const *cur_filename =3D NULL; unsigned long cur_file_idx =3D 0; - int last_line =3D 1; + unsigned int last_line =3D 1; =20 emit_lne_set_address(be, (void *)code_addr); =20 for (i =3D 0; i < nr_entry; i++, ent =3D debug_entry_next(ent)) { int need_copy =3D 0; ubyte special_opcode; + unsigned int lineno =3D get_unaligned(&ent->lineno); + uint64_t addr =3D get_unaligned(&ent->addr); =20 /* * check if filename changed, if so add it @@ -376,24 +382,24 @@ static void emit_lineno_info(struct buffer_ext *be, =20 special_opcode =3D get_special_opcode(ent, last_line, last_vma); if (special_opcode !=3D 0) { - last_line =3D ent->lineno; - last_vma =3D ent->addr; + last_line =3D lineno; + last_vma =3D addr; emit_opcode(be, special_opcode); } else { /* * lines differ, emit line delta */ - if (last_line !=3D ent->lineno) { - emit_advance_lineno(be, ent->lineno - last_line); - last_line =3D ent->lineno; + if (last_line !=3D lineno) { + emit_advance_lineno(be, lineno - last_line); + last_line =3D lineno; need_copy =3D 1; } /* * addresses differ, emit address delta */ - if (last_vma !=3D ent->addr) { - emit_advance_pc(be, ent->addr - last_vma); - last_vma =3D ent->addr; + if (last_vma !=3D addr) { + emit_advance_pc(be, addr - last_vma); + last_vma =3D addr; need_copy =3D 1; } /* @@ -480,7 +486,7 @@ jit_process_debug_info(uint64_t code_addr, int i; =20 for (i =3D 0; i < nr_debug_entries; i++) { - ent->addr =3D ent->addr - code_addr; + put_unaligned(get_unaligned(&ent->addr) - code_addr, &ent->addr); ent =3D debug_entry_next(ent); } add_compilation_unit(di, buffer_ext_size(dl)); --=20 2.55.0 From nobody Sat Sep 26 07:14:43 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CB0CC4AF14B; Thu, 3 Sep 2026 13:23:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788441808; cv=none; b=i7KZTLKzHUAqRLEu6iJRHsCzAYfPUapS1dnZm34Q4z9SJunrUlGyOESF+Yg7ltQLteagvjOoMbeIAb+ogomDW0nhLIvmGrTTDz45K/9ybQfa6v8OqJDmTEVcrTJBSYHh/na8LV6MWc+4bmh36WS29z9SekM5SEYMkB9YNc0icdg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788441808; c=relaxed/simple; bh=5hEhJUAi/thyWbcDgFlB22m8l2sq4GBoKIV1ou5jN8Q=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=W48B695l/rglF7nN3Jhk5A69jFQlUSlHOaJhbRaz3+rb9SaHzOKCLHf1yR+lD7EKRvjHy+/XIgHfTszbqUC02v+npXCo9sC1cNQ1xJzXazXAyCWEfGPwlHyee/D7m9KL3yGI61Vf6x7ZTbG6Eg2oDkF8fG8nFY2hWB9LESGMIWI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=HcdFtvPz; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="HcdFtvPz" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 32D1A1F00ACF; Thu, 3 Sep 2026 13:23:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788441786; bh=FFS9RizjkOWavg/h9KaPhTtsqZ2GndXNrlnfx0cHXJE=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=HcdFtvPzB5hCqDDBCFV6Z/QffAatGji4Mox2ousLXJ8BEvQ4WWFce0ioL6b0cXf8q PtV+ry2zGMhSzM+UTaqetV8JI19Dv7QMeXKV9V4q8qLGx6BPYKYnbcHgANXJWaA98z 60c9ZteFHU3GYlIW70ecZsg5Spi9t27KkpBGE4UPP+8Nb9TlI9cHN1F1BC8aaLpPJS rLeNLNWT+EwH8fP77i1B2Wt9bOYThYlGvUz5ZyVyFo4r0ICCem7H+U7EBlr4FTDVwF RuxRZjWCbdmnl272zwUo3/MXU9/jJF2fYKaKP4E0DcbE7vg+nZqOqDtHqbJEx0Ql71 U4wWF5qWDKYLw== From: Arnaldo Carvalho de Melo To: Namhyung Kim Cc: Ingo Molnar , Thomas Gleixner , James Clark , Jiri Olsa , Ian Rogers , Adrian Hunter , Clark Williams , linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, Arnaldo Carvalho de Melo , sashiko-bot , Stephane Eranian Subject: [PATCH 3/5] perf jitdump: Free unwinding data even when eh_frame_hdr_size is zero Date: Thu, 3 Sep 2026 10:22:49 -0300 Message-ID: <20260903132251.237029-4-acme@kernel.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260903132251.237029-1-acme@kernel.org> References: <20260903132251.237029-1-acme@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Arnaldo Carvalho de Melo jit_repipe_code_load() only cleared the unwinding state when both unwinding_data and eh_frame_hdr_size were set. When a record carries unwinding data but eh_frame_hdr_size is 0, the cleanup condition fails and the unwinding state persists in jd, being applied to all subsequent JIT_CODE_LOAD and JIT_CODE_MOVE records, duplicating unwinding sections in the generated ELF files and inflating their event->mmap2.len. The record is validated upstream so eh_frame_hdr_size <=3D unwinding_size always holds. Free the unwinding data based on the data pointer alone. Reported-by: sashiko-bot Cc: Stephane Eranian Assisted-by: LLM Signed-off-by: Arnaldo Carvalho de Melo Reviewed-by: Ian Rogers --- tools/perf/util/jitdump.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/util/jitdump.c b/tools/perf/util/jitdump.c index e0d5cc9a828189a2..efb40d93e33ae664 100644 --- a/tools/perf/util/jitdump.c +++ b/tools/perf/util/jitdump.c @@ -530,7 +530,7 @@ static int jit_repipe_code_load(struct jit_buf_desc *jd= , union jr_entry *jr) jd->nr_debug_entries =3D 0; } =20 - if (jd->unwinding_data && jd->eh_frame_hdr_size) { + if (jd->unwinding_data) { zfree(&jd->unwinding_data); jd->eh_frame_hdr_size =3D 0; jd->unwinding_mapped_size =3D 0; --=20 2.55.0 From nobody Sat Sep 26 07:14:43 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E09634AF167; Thu, 3 Sep 2026 13:23:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788441805; cv=none; b=o/txpw3Si+Z+NgCwVilG72Vg0x1wvKLVYe0d7pZQiu9M4bibB5jEHjI7irVFZBusghyjAy26As0lLa2EuR42sqfBtVjuYC9AFPFuOZvvBmtm7LGKMxpEps4/SD4GQ8/j3JSgU7bPzuXGRTuq2SABLKJSo/wPpeq10PNgZMoZIqY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788441805; c=relaxed/simple; bh=L94mGG3+amf0Eb6VJeYe7NEefJQ2vWe2zgiYN2nKYuI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=nU5kMWKg73yC4k8ISHPkrKWvMx5zfj8KSvjQWxroGBbMQEggySsLMqtWmbMt0EAsfDiftTSnKqDDSUhdEzKdcF3ig1kC/934h/0HUD7Uazmoz6AjUTkAxAt5GhMYom17seGI9AmFzuPNvVR8nAt3bHJ9Vb7gQXR8zhCtQCMp9Zo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=EehSvjRV; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="EehSvjRV" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 59D381F000E9; Thu, 3 Sep 2026 13:23:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788441790; bh=p9ekETLC2l5v95gbac18OOJQxqsfYxKvXUWjvZAOyBY=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=EehSvjRV8xL3r3wM2Re9JboBAJr0NKClZlXR+nzZz7hbM0fg+7KTAxPgVj2rlzlYT ReKccM0OXXaoC8ldv+Ra/cecHboGdwfCylevbgM5EKx+tO4z+BHtVd2vqIQqScckIU gBfZTWV+JpfN+IN2ke6y6OBEdaqGX68PH65ZyuymhmIcOkf4eVcBHEwKF+RfytQ6J2 1UyLPiXHEIYabU5sK+/hWlpudyMvYRedLmg+xFH++OKhqKlJWX9CPxibMkC10qLjCD UZ87eUPCRkwSg8lPlJsdv9H1acVRcGPxwQING2T1Yf13W6ETms5zbL2s4qgZJwFzDz 1nYIsfww/htMw== From: Arnaldo Carvalho de Melo To: Namhyung Kim Cc: Ingo Molnar , Thomas Gleixner , James Clark , Jiri Olsa , Ian Rogers , Adrian Hunter , Clark Williams , linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, Arnaldo Carvalho de Melo , sashiko-bot , Stephane Eranian Subject: [PATCH 4/5] perf jitdump: Size code_move event allocation with idr_size Date: Thu, 3 Sep 2026 10:22:50 -0300 Message-ID: <20260903132251.237029-5-acme@kernel.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260903132251.237029-1-acme@kernel.org> References: <20260903132251.237029-1-acme@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Arnaldo Carvalho de Melo jit_repipe_code_move() allocated the mmap2 event with a hardcoded +16, but computes event->mmap2.header.size as sizeof(event->mmap2) minus unused filename bytes plus idr_size. When idr_size is larger than 16, header.size exceeds the allocation, so perf_data__write() reads past the heap allocation, leaking adjacent heap memory into the generated perf.data file. Size the allocation with idr_size like jit_repipe_code_load() does. Reported-by: sashiko-bot Cc: Stephane Eranian Assisted-by: LLM Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/util/jitdump.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/tools/perf/util/jitdump.c b/tools/perf/util/jitdump.c index efb40d93e33ae664..689aa0a8c60bcd8b 100644 --- a/tools/perf/util/jitdump.c +++ b/tools/perf/util/jitdump.c @@ -636,9 +636,10 @@ static int jit_repipe_code_move(struct jit_buf_desc *j= d, union jr_entry *jr) idr_size =3D jd->machine->id_hdr_size; =20 /* - * +16 to account for sample_id_all (hack) + * Sample ID is written past the end of the mmap2 record; size + * the allocation to account for it instead of a hardcoded +16. */ - event =3D calloc(1, sizeof(*event) + 16); + event =3D calloc(1, sizeof(*event) + idr_size); if (!event) return -1; =20 --=20 2.55.0 From nobody Sat Sep 26 07:14:43 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A51DE4AEBE8; Thu, 3 Sep 2026 13:23:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788441805; cv=none; b=OuMbgg2IjW0davABYNF51Lb+cqHbZzuWkwzqT3yVvmym4frqF0SkWut7c2vlJGWQtfEm2EiDVky5JjgmvhStDmPaKaoLTEeBdlBtE1TzTwq0sz32syJSyJdxGBOBiIQj256XoH57plPu3bjrIfZ1Bm4Z2OgpIF9keQ9ereOVEYM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788441805; c=relaxed/simple; bh=49Kw97LLSQ4wYGERFAwnuRn8NRTU8dL5rolrv5ESGpg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Xu+FiMGbyXPyO7LjJi3ehgbV2Kw4oYzpeXhu54s9xDcaNmJkroUrcQCwS/ib664Ld7EeP5PrKJqTOWpjTHBGnquc70eC/HLU+b3jmPJYwJjgsp0TrkZDRwdysFs7Y58PVPjE6bAwIYvbXOmxHvXGYicoK6WXx4zy0YHz7ojLuVc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=N9k0+2iW; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="N9k0+2iW" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7F4131F00A3D; Thu, 3 Sep 2026 13:23:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788441793; bh=zVuGCa5JkO9W8qaCsJWajvQZcXk7UK/+LrY4kqAkDVU=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=N9k0+2iWiLbMDV4sX7XBd+Fbq8fG+52A5vi6mKScjW9s1B3GbZ0QmtcWb3v7q9FQu K7BWI5fu4Xn9i7gOH6M/YyKZXMX+1uTfGHZHA5qyA9QqDdiq760ZLVnIas99+SODfJ zg8VQj6mUKnAEKUNyayDx+ruU5qr9xHwD15ph8qVbQpiZT1IULQRNcIR1nhcpCApZC Srq0fcLPqZBsvKadEZI7mchGDxTRXE9Jvvt0HIBeR1Plz41Xxse8b8l9XTwa3ir+FL XwPNR8oUGCtaDMtUVaBkV6G04i+F9SRr3HODJt7hZe9Yog/ZL8nU50SQLLwF2lGw1T 5upiXXjVoohKQ== From: Arnaldo Carvalho de Melo To: Namhyung Kim Cc: Ingo Molnar , Thomas Gleixner , James Clark , Jiri Olsa , Ian Rogers , Adrian Hunter , Clark Williams , linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, Arnaldo Carvalho de Melo , sashiko-bot , Stephane Eranian Subject: [PATCH 5/5] perf dso: Defer dropping the open list reference until after the lock Date: Thu, 3 Sep 2026 10:22:51 -0300 Message-ID: <20260903132251.237029-6-acme@kernel.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260903132251.237029-1-acme@kernel.org> References: <20260903132251.237029-1-acme@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Arnaldo Carvalho de Melo There was a problem in the code with some resources potentially being left unbalanced, and the logic on dso__data_close() becoming confused if the fd had been closed already. The reference taken by dso__list_add() on the open list cannot be dropped while holding the open lock: dso__put() may call dso__data_close(), which takes dso__data_open_lock() itself, deadlocking and leaving the list and its counter inconsistent for concurrent threads. Fix it by changing dso__list_del() to transfer the reference to a deferred node, drained by dso__put_deferred() right after every unlock of dso__data_open_lock(). Since the counter is now decremented under the open lock, do_open()'s close_first_dso() no longer races with a stale count. Reported-by: sashiko-bot Cc: Stephane Eranian Assisted-by: LLM Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/util/dso.c | 75 ++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 71 insertions(+), 4 deletions(-) diff --git a/tools/perf/util/dso.c b/tools/perf/util/dso.c index 42bfe30a3b518e80..a4b2361bc7420084 100644 --- a/tools/perf/util/dso.c +++ b/tools/perf/util/dso.c @@ -531,18 +531,79 @@ static void dso__list_add(struct dso *dso) EXCLUSIVE_= LOCKS_REQUIRED(_dso__data_o dso__data_open_cnt++; } =20 +#ifdef REFCNT_CHECKING +/* + * A deferred put: carries the reference taken by dso__list_add() for an + * entry removed from dso__data_open. Dedicated nodes are used so that + * the dso_data's own open_entry node can be relinked by a concurrent + * dso__list_add() without corrupting this list or its reference. + */ +struct dso_data_put { + struct list_head entry; + struct dso *dso; +}; +static LIST_HEAD(dso__data_open_put); +#endif + static void dso__list_del(struct dso *dso) EXCLUSIVE_LOCKS_REQUIRED(_dso__= data_open_lock) { - list_del_init(&dso__data(dso)->open_entry); #ifdef REFCNT_CHECKING - mutex_unlock(dso__data_open_lock()); - dso__put(dso__data(dso)->dso); - mutex_lock(dso__data_open_lock()); + struct dso_data_put *put; #endif + + list_del_init(&dso__data(dso)->open_entry); WARN_ONCE(dso__data_open_cnt <=3D 0, "DSO data fd counter out of bounds."); dso__data_open_cnt--; +#ifdef REFCNT_CHECKING + /* + * The reference taken in dso__list_add() cannot be dropped while + * holding the open lock: dso__put() may call dso__data_close(), + * which takes dso__data_open_lock itself, deadlocking and leaving + * the list/counter state inconsistent for concurrent threads. + * Transfer the reference to a deferred node drained by + * dso__put_deferred() once the lock is released. + */ + put =3D zalloc(sizeof(*put)); + + if (put =3D=3D NULL) + return; + + put->dso =3D dso__data(dso)->dso; + dso__data(dso)->dso =3D NULL; + list_add_tail(&put->entry, &dso__data_open_put); +#endif +} + +#ifdef REFCNT_CHECKING +/* + * Drop the references deferred by dso__list_del(). Must be called + * without holding dso__data_open_lock: dso__put() may re-enter it via + * dso__data_close(). + */ +static void dso__put_deferred(void) LOCKS_EXCLUDED(_dso__data_open_lock) +{ + for (;;) { + struct dso_data_put *put; + struct dso *dso; + + mutex_lock(dso__data_open_lock()); + put =3D list_first_entry_or_null(&dso__data_open_put, struct dso_data_pu= t, entry); + if (put =3D=3D NULL) { + mutex_unlock(dso__data_open_lock()); + return; + } + list_del_init(&put->entry); + dso =3D put->dso; + mutex_unlock(dso__data_open_lock()); + + free(put); + dso__put(dso); + } } +#else +static void dso__put_deferred(void) {} +#endif =20 static void close_first_dso(void); =20 @@ -805,6 +866,7 @@ void dso__data_close(struct dso *dso) mutex_lock(dso__data_open_lock()); close_dso(dso); mutex_unlock(dso__data_open_lock()); + dso__put_deferred(); } =20 static void try_to_open_dso(struct dso *dso, struct machine *machine) @@ -865,12 +927,14 @@ bool dso__data_get_fd(struct dso *dso, struct machine= *machine, int *fd) return true; =20 mutex_unlock(dso__data_open_lock()); + dso__put_deferred(); return false; } =20 void dso__data_put_fd(struct dso *dso __maybe_unused) { mutex_unlock(dso__data_open_lock()); + dso__put_deferred(); } =20 bool dso__data_status_seen(struct dso *dso, enum dso_data_status_seen by) @@ -1058,6 +1122,7 @@ static ssize_t file_read(struct dso *dso, struct mach= ine *machine, ret =3D pread(dso__data(dso)->fd, data, DSO__DATA_CACHE_SIZE, offset); out: mutex_unlock(dso__data_open_lock()); + dso__put_deferred(); return ret; } =20 @@ -1188,6 +1253,7 @@ static int file_size(struct dso *dso, struct machine = *machine) =20 out: mutex_unlock(dso__data_open_lock()); + dso__put_deferred(); return ret; } =20 @@ -1405,6 +1471,7 @@ uint16_t dso__e_machine_endian(struct dso *dso, struc= t machine *machine, uint32_ *e_flags =3D 0; =20 mutex_unlock(dso__data_open_lock()); + dso__put_deferred(); return e_machine; } =20 --=20 2.55.0