From: Ian Rogers <irogers@google.com>
To: irogers@google.com, acme@kernel.org, adrian.hunter@intel.com,
james.clark@linaro.org, jolsa@kernel.org, mingo@redhat.com,
namhyung@kernel.org, peterz@infradead.org
Cc: alexander.shishkin@linux.intel.com, alexei.starovoitov@gmail.com,
andrii@kernel.org, ast@kernel.org, bpf@vger.kernel.org,
daniel@iogearbox.net, eddyz87@gmail.com, haoluo@google.com,
john.fastabend@gmail.com, kpsingh@kernel.org,
linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org,
martin.lau@linux.dev, memxor@gmail.com, sdf@fomichev.me,
song@kernel.org, yonghong.song@linux.dev
Subject: [PATCH v2 3/4] perf hashmap: Fix strict aliasing violations in hashmap
Date: Sat, 21 Mar 2026 17:58:22 -0700 [thread overview]
Message-ID: <20260322005823.981079-4-irogers@google.com> (raw)
In-Reply-To: <20260322005823.981079-1-irogers@google.com>
The hashmap in perf util (copied from libbpf) contained strict
aliasing violations. Specifically, the hashmap_cast_ptr(p) macro was
casting pointers (such as void **) to long *, and these were
subsequently dereferenced in functions like hashmap_insert(),
hashmap_find(), and hashmap_delete().
C's strict aliasing rules (C11 6.5/7) prohibit accessing an object
through an lvalue of an incompatible type. Dereferencing a long * to
write to a void * object is a violation, even if they share the same
size, as they are not compatible types. This can lead to undefined
behavior, especially with aggressive compiler optimizations.
Fix this by:
1. Updating hashmap_insert(), hashmap_find(), and hashmap_delete() to
take void * for their output parameters (old_key, old_value, and
value).
2. Modifying the implementation to use memcpy() and memset() for
accessing these output parameters. Accessing an object as an array of
characters (as done by memcpy) is a permitted exception to the
strict aliasing rules.
3. Updating the hashmap_cast_ptr(p) macro to return void *, ensuring
compatibility with the new function signatures while preserving the
static assertion that ensures the pointed-to type matches the size of
a long.
Input parameters (key and value) remain as long, as they involve value
conversion rather than incompatible pointer dereferencing, which is safe
under strict aliasing rules.
Signed-off-by: Ian Rogers <irogers@google.com>
---
tools/perf/util/hashmap.c | 21 +++++++++++----------
tools/perf/util/hashmap.h | 8 ++++----
2 files changed, 15 insertions(+), 14 deletions(-)
diff --git a/tools/perf/util/hashmap.c b/tools/perf/util/hashmap.c
index 8c4b1f2af3ed..d90ef4ed384d 100644
--- a/tools/perf/util/hashmap.c
+++ b/tools/perf/util/hashmap.c
@@ -8,6 +8,7 @@
#include <stdint.h>
#include <stdlib.h>
#include <stdio.h>
+#include <string.h>
#include <errno.h>
#include <linux/err.h>
#include "hashmap.h"
@@ -153,24 +154,24 @@ static bool perf_hashmap_find_entry(const struct perf_hashmap *map,
int perf_hashmap_insert(struct perf_hashmap *map, long key, long value,
enum perf_hashmap_insert_strategy strategy,
- long *old_key, long *old_value)
+ void *old_key, void *old_value)
{
struct perf_hashmap_entry *entry;
size_t h;
int err;
if (old_key)
- *old_key = 0;
+ memset(old_key, 0, sizeof(long));
if (old_value)
- *old_value = 0;
+ memset(old_value, 0, sizeof(long));
h = hash_bits(map->hash_fn(key, map->ctx), map->cap_bits);
if (strategy != PERF_HASHMAP_APPEND &&
perf_hashmap_find_entry(map, key, h, NULL, &entry)) {
if (old_key)
- *old_key = entry->key;
+ memcpy(old_key, &entry->key, sizeof(long));
if (old_value)
- *old_value = entry->value;
+ memcpy(old_value, &entry->value, sizeof(long));
if (strategy == PERF_HASHMAP_SET || strategy == PERF_HASHMAP_UPDATE) {
entry->key = key;
@@ -203,7 +204,7 @@ int perf_hashmap_insert(struct perf_hashmap *map, long key, long value,
return 0;
}
-bool perf_hashmap_find(const struct perf_hashmap *map, long key, long *value)
+bool perf_hashmap_find(const struct perf_hashmap *map, long key, void *value)
{
struct perf_hashmap_entry *entry;
size_t h;
@@ -213,12 +214,12 @@ bool perf_hashmap_find(const struct perf_hashmap *map, long key, long *value)
return false;
if (value)
- *value = entry->value;
+ memcpy(value, &entry->value, sizeof(long));
return true;
}
bool perf_hashmap_delete(struct perf_hashmap *map, long key,
- long *old_key, long *old_value)
+ void *old_key, void *old_value)
{
struct perf_hashmap_entry **pprev, *entry;
size_t h;
@@ -228,9 +229,9 @@ bool perf_hashmap_delete(struct perf_hashmap *map, long key,
return false;
if (old_key)
- *old_key = entry->key;
+ memcpy(old_key, &entry->key, sizeof(long));
if (old_value)
- *old_value = entry->value;
+ memcpy(old_value, &entry->value, sizeof(long));
perf_hashmap_del_entry(pprev, entry);
free(entry);
diff --git a/tools/perf/util/hashmap.h b/tools/perf/util/hashmap.h
index 310b08c0b669..51ad25dd9980 100644
--- a/tools/perf/util/hashmap.h
+++ b/tools/perf/util/hashmap.h
@@ -116,7 +116,7 @@ enum perf_hashmap_insert_strategy {
_Static_assert((__builtin_constant_p((p)) ? (p) == NULL : 0) || \
sizeof(*(p)) == sizeof(long), \
#p " pointee should be a long-sized integer or a pointer"); \
- (long *)(p); \
+ (void *)(p); \
})
/*
@@ -128,7 +128,7 @@ enum perf_hashmap_insert_strategy {
*/
int perf_hashmap_insert(struct perf_hashmap *map, long key, long value,
enum perf_hashmap_insert_strategy strategy,
- long *old_key, long *old_value);
+ void *old_key, void *old_value);
#define perf_hashmap__insert(map, key, value, strategy, old_key, old_value) \
perf_hashmap_insert((map), (long)(key), (long)(value), (strategy), \
@@ -147,14 +147,14 @@ int perf_hashmap_insert(struct perf_hashmap *map, long key, long value,
#define perf_hashmap__append(map, key, value) \
perf_hashmap__insert((map), (key), (value), PERF_HASHMAP_APPEND, NULL, NULL)
-bool perf_hashmap_delete(struct perf_hashmap *map, long key, long *old_key, long *old_value);
+bool perf_hashmap_delete(struct perf_hashmap *map, long key, void *old_key, void *old_value);
#define perf_hashmap__delete(map, key, old_key, old_value) \
perf_hashmap_delete((map), (long)(key), \
perf_hashmap_cast_ptr(old_key), \
perf_hashmap_cast_ptr(old_value))
-bool perf_hashmap_find(const struct perf_hashmap *map, long key, long *value);
+bool perf_hashmap_find(const struct perf_hashmap *map, long key, void *value);
#define perf_hashmap__find(map, key, value) \
perf_hashmap_find((map), (long)(key), perf_hashmap_cast_ptr(value))
--
2.53.0.959.g497ff81fa9-goog
next prev parent reply other threads:[~2026-03-22 0:58 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-21 2:44 [PATCH v1 1/2] libbpf: Fix strict aliasing violations in hashmap Ian Rogers
2026-03-21 2:44 ` [PATCH v1 2/2] perf tools: " Ian Rogers
2026-03-21 12:37 ` [PATCH v1 1/2] libbpf: " sun jian
2026-03-21 15:40 ` Yonghong Song
2026-03-21 17:36 ` Kumar Kartikeya Dwivedi
2026-03-21 19:49 ` Alexei Starovoitov
2026-03-21 23:04 ` Ian Rogers
2026-03-21 23:08 ` Alexei Starovoitov
2026-03-21 23:10 ` Ian Rogers
2026-03-22 0:58 ` [PATCH v2 0/4] perf hashmap: Separate perf's hashmap code from libbpf Ian Rogers
2026-03-22 0:58 ` [PATCH v2 1/4] perf build: Don't check difference of perf and libbpf hashmap Ian Rogers
2026-03-22 0:58 ` [PATCH v2 2/4] perf hashmap: Rename hashmap to perf_hashmap to avoid libbpf conflict Ian Rogers
2026-03-22 0:58 ` Ian Rogers [this message]
2026-03-22 0:58 ` [PATCH v2 4/4] perf hashmap: Remove errptr usage from hashmap Ian Rogers
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=20260322005823.981079-4-irogers@google.com \
--to=irogers@google.com \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=alexei.starovoitov@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=haoluo@google.com \
--cc=james.clark@linaro.org \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=martin.lau@linux.dev \
--cc=memxor@gmail.com \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=sdf@fomichev.me \
--cc=song@kernel.org \
--cc=yonghong.song@linux.dev \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox