From nobody Mon Feb 9 05:59:16 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 83708142E78; Fri, 12 Apr 2024 18:33:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712946793; cv=none; b=EWejSM85wUsrZRy6edJ01yLFiXbba2xFPFg+Il0S6ERpEWKX7nm9xzyohJnKw4fLlcfPc71S/NDL6ZoYz45sNRciEp/bxiO4mHNokxLrw+sOdwgrcFr3jykyjgvMSwE2djk+OF1f5IyDUWUZwNP3OEyAM/Z8asF1raqfdCglZcQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712946793; c=relaxed/simple; bh=d46/j7SfBjlB5pOHNg/gyQVFI44DuFqnaghicJF9/+0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=cfrmTcP6kK342u3EIYTamiBVTSuGKgSnXDLzvW1nf6dgazr09zN83GRlmo+WZK5TF1vq2Uurl9VwCA9M60yyOtt92aKEZQnSJIj9nqyoQVbt4IwE97P2V5efQo6LWHsbPVOfiggYc/oV/+leLcgUsbdKum26z3M1TKjYnerAeZQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=hGRJdUmR; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="hGRJdUmR" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 069A6C4AF0F; Fri, 12 Apr 2024 18:33:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1712946793; bh=d46/j7SfBjlB5pOHNg/gyQVFI44DuFqnaghicJF9/+0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=hGRJdUmRz6JuH14PX2oW4J4iKBjLs5L9muwe1c2FZK29AehqdZ31TOhFYx5EhswF5 BsY0I9tseGqOdZPk7PPwZ6IHEeff65pklUfyKU+Um97Wg0rMcBjnw+csgugB9hFBcY 4/d/SdQtmJcKigKH8GNQD9+e2d2idRXzcZmISzH4e/EyyoMUwHyXBj1/laeRVFsKV3 1HbkK+FZXUBTY/XfRuPyLDgkQ16V07C1ojJZOCJbjcLG8myUlu52tCHCET7deHfNgV FyCLTOs1z0FntzEseAYfggLgmvCfnQpNdVaaOlDYdKoJcUMMlLhdaQlkb3Ut6CaJVe rOHkpCkLIFXcA== From: Namhyung Kim To: Arnaldo Carvalho de Melo , Ian Rogers , Kan Liang Cc: Jiri Olsa , Adrian Hunter , Peter Zijlstra , Ingo Molnar , LKML , linux-perf-users@vger.kernel.org, Masami Hiramatsu Subject: [PATCH 3/4] perf dwarf-aux: Check variable address range properly Date: Fri, 12 Apr 2024 11:33:09 -0700 Message-ID: <20240412183310.2518474-4-namhyung@kernel.org> X-Mailer: git-send-email 2.44.0.683.g7961c838ac-goog In-Reply-To: <20240412183310.2518474-1-namhyung@kernel.org> References: <20240412183310.2518474-1-namhyung@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" In match_var_offset(), it just checked the end address of the variable with the given offset because it assumed the register holds a pointer to the data type and the offset starts from the base. But I found some cases that the stack pointer (rsp =3D reg7) register is used to pointer a stack variable while the frame base is maintained by a different register (rbp =3D reg6). In that case, it cannot simply use the stack pointer as it cannot guarantee that it points to the frame base. So it needs to check the both boundaries of the variable location. Before: ----------------------------------------------------------- find data type for 0x7c(reg7) at tcp_getsockopt+0xb62 CU for net/ipv4/tcp.c (die:0x7b5f516) frame base: cfa=3D0 fbreg=3D6 no pointer or no type check variable "tss" failed (die: 0x7b95801) variable location: base reg7, offset=3D0x110 type=3D'struct scm_timestamping_internal' size=3D0x30 (die:0x7b8c126) So the current code just checks register number for the non-PC and non-FB registers and assuming it has offset 0. But this variable has offset 0x110 so it should not match to this. After: ----------------------------------------------------------- find data type for 0x7c(reg7) at tcp_getsockopt+0xb62 CU for net/ipv4/tcp.c (die:0x7b5f516) frame base: cfa=3D0 fbreg=3D6 no pointer or no type check variable "zc" failed (die: 0x7b9580a) variable location: base=3Dreg7, offset=3D0x40 type=3D'struct tcp_zerocopy_receive' size=3D0x40 (die:7b947f4) Now it find the correct variable "zc". It was located at reg7 + 0x40 and the size if 0x40 which means it should cover [0x40, 0x80). And the access was for reg7 + 0x7c so it found the right one. But it still failed to use the variable and it would be handled in the next patch. Cc: Masami Hiramatsu Signed-off-by: Namhyung Kim --- tools/perf/util/dwarf-aux.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/tools/perf/util/dwarf-aux.c b/tools/perf/util/dwarf-aux.c index b361fd7ebd56..40cfbdfe2d75 100644 --- a/tools/perf/util/dwarf-aux.c +++ b/tools/perf/util/dwarf-aux.c @@ -1372,6 +1372,9 @@ static bool match_var_offset(Dwarf_Die *die_mem, stru= ct find_var_data *data, return true; } =20 + if (addr_offset < addr_type) + return false; + if (die_get_real_type(die_mem, &type_die) =3D=3D NULL) return false; =20 @@ -1446,7 +1449,6 @@ static int __die_find_var_reg_cb(Dwarf_Die *die_mem, = void *arg) =20 /* Local variables accessed using frame base register */ if (data->is_fbreg && ops->atom =3D=3D DW_OP_fbreg && - data->offset >=3D (int)ops->number && check_allowed_ops(ops, nops) && match_var_offset(die_mem, data, data->offset, ops->number, /*is_pointer=3D*/false)) @@ -1537,9 +1539,6 @@ static int __die_find_var_addr_cb(Dwarf_Die *die_mem,= void *arg) if (ops->atom !=3D DW_OP_addr) continue; =20 - if (data->addr < ops->number) - continue; - if (check_allowed_ops(ops, nops) && match_var_offset(die_mem, data, data->addr, ops->number, /*is_pointer=3D*/false)) --=20 2.44.0.683.g7961c838ac-goog