From nobody Mon Feb 9 20:30:24 2026 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 2CB1516C451; Tue, 7 May 2024 14:12:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1715091201; cv=none; b=tVq3Hd2lC+1mH/bEl69B4w1PgBgQvWUw4KW+R+33lFqFeRWszNTlgo+IDvClBBDUWEHXeJjz47cvZ0ylcLQ+Icayao8i9i9ccvMiuOp+LTlNqM/H3L5FoMteuWMyIdXW/Up4jkV01k5Gf3QPJD+8DSWQB28+r+jDUHljFj6PTXg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1715091201; c=relaxed/simple; bh=FPYdBnC0kccxQTzIc3GnR8aqAfAzYDsn2eFN0I7vXyU=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=b36N5FPsx5JDmlFawbl3Ld800MlStSi9q7z+HH+xy8Cir/jjCXiWfKMTPgqRwH68YvKtQUqOKC6yBPbNYGaeQASVxhIqGHoMKvVwO1/zacN6dJ6zd5VvUj18j00EkhbNkYwJ4oKsToJ1hy4ffh5bKlwjv5Pv7apPhpCVRiQ5q3Q= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 6E964106F; Tue, 7 May 2024 07:13:25 -0700 (PDT) Received: from e127643.broadband (usa-sjc-mx-foss1.foss.arm.com [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 8CDB13F6A8; Tue, 7 May 2024 07:12:57 -0700 (PDT) From: James Clark To: linux-perf-users@vger.kernel.org, atrajeev@linux.vnet.ibm.com, irogers@google.com Cc: James Clark , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , Mark Rutland , Alexander Shishkin , Jiri Olsa , Adrian Hunter , "Liang, Kan" , linux-kernel@vger.kernel.org Subject: [PATCH 1/4] perf symbols: Remove map from list before updating addresses Date: Tue, 7 May 2024 15:12:05 +0100 Message-Id: <20240507141210.195939-2-james.clark@arm.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240507141210.195939-1-james.clark@arm.com> References: <20240507141210.195939-1-james.clark@arm.com> 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" Make the order of operations remove, update, add. Updating addresses before the map is removed causes the ordering check to fail when the map is removed. This can be reproduced when running Perf on an Arm system with a static kernel and Perf uses kcore rather than other sources: $ perf record -- ls $ perf report util/maps.c:96: check_invariants: Assertion `map__end(prev) <=3D map__start(map) || map__start(prev) =3D=3D map__start(map)' failed Fixes: 659ad3492b91 ("perf maps: Switch from rbtree to lazily sorted array = for addresses") Signed-off-by: James Clark --- tools/perf/util/symbol.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c index 7772a4d3e66c..2d95f22d713d 100644 --- a/tools/perf/util/symbol.c +++ b/tools/perf/util/symbol.c @@ -1377,13 +1377,15 @@ static int dso__load_kcore(struct dso *dso, struct = map *map, if (RC_CHK_EQUAL(new_map, replacement_map)) { struct map *map_ref; =20 - map__set_start(map, map__start(new_map)); - map__set_end(map, map__end(new_map)); - map__set_pgoff(map, map__pgoff(new_map)); - map__set_mapping_type(map, map__mapping_type(new_map)); /* Ensure maps are correctly ordered */ map_ref =3D map__get(map); maps__remove(kmaps, map_ref); + + map__set_start(map_ref, map__start(new_map)); + map__set_end(map_ref, map__end(new_map)); + map__set_pgoff(map_ref, map__pgoff(new_map)); + map__set_mapping_type(map_ref, map__mapping_type(new_map)); + err =3D maps__insert(kmaps, map_ref); map__put(map_ref); map__put(new_map); --=20 2.34.1 From nobody Mon Feb 9 20:30:24 2026 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 4CC8516C849; Tue, 7 May 2024 14:13:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1715091204; cv=none; b=X9lldrCbSHcXsybgzwVxKUyKFABF/zu9jP/yCM/xUaMIdbGsFR+ya/I1qK9leckXl1vGFlltO3y70wRMHzEF3DOqrJgVeTVA621zppTFmk0AjAQ+6YPikZ+zmCFO3Gu3a9TpMTZdQSnE/i9sfB3xTn/l6c39yrRIGGxCt5zYDwI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1715091204; c=relaxed/simple; bh=sE3X07S6/95vfe+bBwB2Qtkb4OMn+hxVPTR3EAq1XMs=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=rF4M9F3yC2QuKs1kXB6DZHFsjUDxYv9b0jrieqi7KgIZMix1Qf/AFcsGhsACNw1M6g2OMWiun20qY6F2P5znXNumHAMmRIuxfClLL0VhwBEm43VbmRhCncfhncPaiFoR2AyA/oO+0vOguEqQxxS0Rd98LZD7ziaT2CFkIqQSLiY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 595341515; Tue, 7 May 2024 07:13:29 -0700 (PDT) Received: from e127643.broadband (usa-sjc-mx-foss1.foss.arm.com [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 78FCB3F6A8; Tue, 7 May 2024 07:13:01 -0700 (PDT) From: James Clark To: linux-perf-users@vger.kernel.org, atrajeev@linux.vnet.ibm.com, irogers@google.com Cc: James Clark , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , Mark Rutland , Alexander Shishkin , Jiri Olsa , Adrian Hunter , "Liang, Kan" , linux-kernel@vger.kernel.org Subject: [PATCH 2/4] perf maps: Re-use __maps__free_maps_by_name() Date: Tue, 7 May 2024 15:12:06 +0100 Message-Id: <20240507141210.195939-3-james.clark@arm.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240507141210.195939-1-james.clark@arm.com> References: <20240507141210.195939-1-james.clark@arm.com> 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" maps__merge_in() hard codes the steps to free the maps_by_name list. It seems to not map__put() each element before freeing, and it sets maps_by_name_sorted to true after freeing, which may be harmless but is inconsistent with maps__init() and other functions. maps__maps_by_name_addr() is also quite hard to read because we already have maps__maps_by_name() and maps__maps_by_address(), but the function is only used in that place so delete it. Signed-off-by: James Clark Reviewed-by: Ian Rogers --- tools/perf/util/maps.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/tools/perf/util/maps.c b/tools/perf/util/maps.c index 61eb742d91e3..16b39db594f4 100644 --- a/tools/perf/util/maps.c +++ b/tools/perf/util/maps.c @@ -124,11 +124,6 @@ static void maps__set_maps_by_address(struct maps *map= s, struct map **new) =20 } =20 -static struct map ***maps__maps_by_name_addr(struct maps *maps) -{ - return &RC_CHK_ACCESS(maps)->maps_by_name; -} - static void maps__set_nr_maps_allocated(struct maps *maps, unsigned int nr= _maps_allocated) { RC_CHK_ACCESS(maps)->nr_maps_allocated =3D nr_maps_allocated; @@ -284,6 +279,9 @@ void maps__put(struct maps *maps) =20 static void __maps__free_maps_by_name(struct maps *maps) { + if (!maps__maps_by_name(maps)) + return; + /* * Free everything to try to do it from the rbtree in the next search */ @@ -291,6 +289,9 @@ static void __maps__free_maps_by_name(struct maps *maps) map__put(maps__maps_by_name(maps)[i]); =20 zfree(&RC_CHK_ACCESS(maps)->maps_by_name); + + /* Consistent with maps__init(). When maps_by_name =3D=3D NULL, maps_by_n= ame_sorted =3D=3D false */ + maps__set_maps_by_name_sorted(maps, false); } =20 static int map__start_cmp(const void *a, const void *b) @@ -1167,8 +1168,7 @@ int maps__merge_in(struct maps *kmaps, struct map *ne= w_map) } maps__set_maps_by_address(kmaps, merged_maps_by_address); maps__set_maps_by_address_sorted(kmaps, true); - zfree(maps__maps_by_name_addr(kmaps)); - maps__set_maps_by_name_sorted(kmaps, true); + __maps__free_maps_by_name(kmaps); maps__set_nr_maps_allocated(kmaps, merged_nr_maps_allocated); =20 /* Copy entries before the new_map that can't overlap. */ --=20 2.34.1 From nobody Mon Feb 9 20:30:24 2026 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 6EE0616D32E; Tue, 7 May 2024 14:13:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1715091213; cv=none; b=JLzbQVTh4g7WQ3NKCxqwxdaDs065pWALb3NcrpHnn46TL8f7zW1hEMaC7m7gjr6JU8MaQd30TR6TPAiYyD8iwz0XXinPoGx87xb8nXbMaeCoNZYNiVQDvOADKn7APmlna/rRj0hJ4mpgy/69UR/Zu3PvdX4UxJzD01CcSFoOw0k= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1715091213; c=relaxed/simple; bh=j60Lp76p4GCMge0RHYRlaMeijthkr1haXgYWLgtV6oU=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=IO6emxOByH9u6Q5Bv/0eVVneLeR4EvvE5zZhrGZjEQjwvBrQWX5lKm+K1NiJnZ1lzm7tgIPvC/W8JqbfmDYFmG+cpIePwm5T79L9sxKIz4g7HmFnF/RnNRRW941uNh54lfBHvrogx2HeOKft7rlosPJinhC4kD7u3/TNvLn2S+w= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 498F51516; Tue, 7 May 2024 07:13:33 -0700 (PDT) Received: from e127643.broadband (usa-sjc-mx-foss1.foss.arm.com [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 687C93F6A8; Tue, 7 May 2024 07:13:05 -0700 (PDT) From: James Clark To: linux-perf-users@vger.kernel.org, atrajeev@linux.vnet.ibm.com, irogers@google.com Cc: James Clark , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , Mark Rutland , Alexander Shishkin , Jiri Olsa , Adrian Hunter , "Liang, Kan" , linux-kernel@vger.kernel.org Subject: [PATCH 3/4] perf symbols: Update kcore map before merging in remaining symbols Date: Tue, 7 May 2024 15:12:07 +0100 Message-Id: <20240507141210.195939-4-james.clark@arm.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240507141210.195939-1-james.clark@arm.com> References: <20240507141210.195939-1-james.clark@arm.com> 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" When loading kcore, the main vmlinux map is updated in the same loop that merges the remaining maps. If a map that overlaps is merged in before kcore, the list can become unsortable when the main map addresses are updated. This will later trigger the check_invariants() assert: $ perf record $ perf report util/maps.c:96: check_invariants: Assertion `map__end(prev) <=3D map__start(map) || map__start(prev) =3D=3D map__start(map)' failed. Aborted Fix it by moving the main map update prior to the loop so that maps__merge_in() can split it if necessary. Fixes: 659ad3492b91 ("perf maps: Switch from rbtree to lazily sorted array = for addresses") Signed-off-by: James Clark --- tools/perf/util/symbol.c | 40 +++++++++++++++++++++------------------- 1 file changed, 21 insertions(+), 19 deletions(-) diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c index 2d95f22d713d..e98dfe766da3 100644 --- a/tools/perf/util/symbol.c +++ b/tools/perf/util/symbol.c @@ -1289,7 +1289,7 @@ static int dso__load_kcore(struct dso *dso, struct ma= p *map, { struct maps *kmaps =3D map__kmaps(map); struct kcore_mapfn_data md; - struct map *replacement_map =3D NULL; + struct map *map_ref, *replacement_map =3D NULL; struct machine *machine; bool is_64_bit; int err, fd; @@ -1367,6 +1367,24 @@ static int dso__load_kcore(struct dso *dso, struct m= ap *map, if (!replacement_map) replacement_map =3D list_entry(md.maps.next, struct map_list_node, node)= ->map; =20 + /* + * Update addresses of vmlinux map. Re-insert it to ensure maps are + * correctly ordered. Do this before using maps__merge_in() for the + * remaining maps so vmlinux gets split if necessary. + */ + map_ref =3D map__get(map); + maps__remove(kmaps, map_ref); + + map__set_start(map_ref, map__start(replacement_map)); + map__set_end(map_ref, map__end(replacement_map)); + map__set_pgoff(map_ref, map__pgoff(replacement_map)); + map__set_mapping_type(map_ref, map__mapping_type(replacement_map)); + + err =3D maps__insert(kmaps, map_ref); + map__put(map_ref); + if (err) + goto out_err; + /* Add new maps */ while (!list_empty(&md.maps)) { struct map_list_node *new_node =3D list_entry(md.maps.next, struct map_l= ist_node, node); @@ -1374,24 +1392,8 @@ static int dso__load_kcore(struct dso *dso, struct m= ap *map, =20 list_del_init(&new_node->node); =20 - if (RC_CHK_EQUAL(new_map, replacement_map)) { - struct map *map_ref; - - /* Ensure maps are correctly ordered */ - map_ref =3D map__get(map); - maps__remove(kmaps, map_ref); - - map__set_start(map_ref, map__start(new_map)); - map__set_end(map_ref, map__end(new_map)); - map__set_pgoff(map_ref, map__pgoff(new_map)); - map__set_mapping_type(map_ref, map__mapping_type(new_map)); - - err =3D maps__insert(kmaps, map_ref); - map__put(map_ref); - map__put(new_map); - if (err) - goto out_err; - } else { + /* skip if replacement_map, already inserted above */ + if (!RC_CHK_EQUAL(new_map, replacement_map)) { /* * Merge kcore map into existing maps, * and ensure that current maps (eBPF) --=20 2.34.1 From nobody Mon Feb 9 20:30:24 2026 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 201EA16D33F; Tue, 7 May 2024 14:13:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1715091210; cv=none; b=Dw4pKPJ4l+r9xjCtHduNBzu241IrbY48vZsO2/sYMqU54/L5X/ZdxAqBnnG22hcpIR+XnDAbyxCQPXPWt+3l3KBEMF6Tn29DknVoy15PV52LOFRL9wTRWy7/hyySslE3hjKL+Tf7UvTGvZvhKjiKgwioPEako3HnxkSdnQ1Jqb0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1715091210; c=relaxed/simple; bh=inoTy0XjeXCVYFWYhXWKSmRMDG/2+bgKHRzwgIGvl9Y=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=duOZBVqt5uDD2GQckRnqVFmuRDZujORD09WVQkXRR6SR+0Rhv1q0fs8mgXRJSivYWFQy9cRRQOJXsxgTsnqrC7OIqzhlTvmTOuvXrWWjLuvNK0z/kN9m2/RU+jsVnZg9otd6/fYV6ziIVXEJv0cjXod8Uo7BGOFteaHThdYamVM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 6E6BF153B; Tue, 7 May 2024 07:13:37 -0700 (PDT) Received: from e127643.broadband (usa-sjc-mx-foss1.foss.arm.com [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 2D7BF3F6A8; Tue, 7 May 2024 07:13:09 -0700 (PDT) From: James Clark To: linux-perf-users@vger.kernel.org, atrajeev@linux.vnet.ibm.com, irogers@google.com Cc: James Clark , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , Mark Rutland , Alexander Shishkin , Jiri Olsa , Adrian Hunter , "Liang, Kan" , linux-kernel@vger.kernel.org Subject: [PATCH 4/4] perf symbols: Fix ownership of string in dso__load_vmlinux() Date: Tue, 7 May 2024 15:12:08 +0100 Message-Id: <20240507141210.195939-5-james.clark@arm.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240507141210.195939-1-james.clark@arm.com> References: <20240507141210.195939-1-james.clark@arm.com> 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" The linked commit updated dso__load_vmlinux() to call dso__set_long_name() before loading the symbols. Loading the symbols may not succeed but dso__set_long_name() takes ownership of the string. The two callers of this function free the string themselves on failure cases, resulting in the following error: $ perf record -- ls $ perf report free(): double free detected in tcache 2 Fix it by always taking ownership of the string, even on failure. This means the string is either freed at the very first early exit condition, or later when the dso is deleted or the long name is replaced. Now no special return value is needed to signify that the caller needs to free the string. Fixes: e59fea47f83e ("perf symbols: Fix DSO kernel load and symbol process = to correctly map DSO to its long_name, type and adjust_symbols") Signed-off-by: James Clark Reviewed-by: Ian Rogers --- tools/perf/util/symbol.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c index e98dfe766da3..6a0900dcdfd3 100644 --- a/tools/perf/util/symbol.c +++ b/tools/perf/util/symbol.c @@ -1977,6 +1977,10 @@ int dso__load(struct dso *dso, struct map *map) return ret; } =20 +/* + * Always takes ownership of vmlinux when vmlinux_allocated =3D=3D true, e= ven if + * it returns an error. + */ int dso__load_vmlinux(struct dso *dso, struct map *map, const char *vmlinux, bool vmlinux_allocated) { @@ -1995,8 +1999,11 @@ int dso__load_vmlinux(struct dso *dso, struct map *m= ap, else symtab_type =3D DSO_BINARY_TYPE__VMLINUX; =20 - if (symsrc__init(&ss, dso, symfs_vmlinux, symtab_type)) + if (symsrc__init(&ss, dso, symfs_vmlinux, symtab_type)) { + if (vmlinux_allocated) + free((char *) vmlinux); return -1; + } =20 /* * dso__load_sym() may copy 'dso' which will result in the copies having @@ -2039,7 +2046,6 @@ int dso__load_vmlinux_path(struct dso *dso, struct ma= p *map) err =3D dso__load_vmlinux(dso, map, filename, true); if (err > 0) goto out; - free(filename); } out: return err; @@ -2191,7 +2197,6 @@ static int dso__load_kernel_sym(struct dso *dso, stru= ct map *map) err =3D dso__load_vmlinux(dso, map, filename, true); if (err > 0) return err; - free(filename); } =20 if (!symbol_conf.ignore_vmlinux && vmlinux_path !=3D NULL) { --=20 2.34.1