From: "Alexei Starovoitov" <alexei.starovoitov@gmail.com>
To: "T.J. Mercier" <tjmercier@google.com>, <daniel@iogearbox.net>,
<andrii@kernel.org>, <eddyz87@gmail.com>, <memxor@gmail.com>,
<martin.lau@linux.dev>, <song@kernel.org>,
<yonghong.song@linux.dev>, <jolsa@kernel.org>,
<emil@etsalapatis.com>, <ihor.solodrai@linux.dev>,
<mykyta.yatsenko5@gmail.com>
Cc: <bpf@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH bpf-next v8 2/2] bpf: htab: Reduce elem_size by 8 bytes for small key sizes
Date: Sat, 03 Oct 2026 06:41:48 +0000 [thread overview]
Message-ID: <DLUZYDAX6849.KKV543CJGGXH@gmail.com> (raw)
In-Reply-To: <20261002161738.621133-3-tjmercier@google.com>
On Fri, Oct 02, 2026 at 09:17 AM T.J. Mercier <tjmercier@google.com> wrote:
> +static __always_inline struct htab_elem *
> +__lookup_elem_raw(struct bpf_htab *htab, struct hlist_nulls_head *head,
> + u32 hash, void *key, u32 key_size,
> + struct hlist_nulls_node **out_n)
> {
> struct hlist_nulls_node *n;
> struct htab_elem *l;
>
> - hlist_nulls_for_each_entry_rcu(l, n, head, hash_node)
> - if (l->hash == hash && !memcmp(&l->key, key, key_size))
> - return l;
> + if (htab_has_hash(htab)) {
[...]
> + unsigned long k = 0;
> +
> + memcpy(&k, key, key_size);
My bot is saying that this will break 32-bit builds with FORTIFY_SOURCE.
__htab_map_lookup_elem_u64() inlines all of it with key_size == 8.
has_hash is a run-time load, so the compiler has to keep this branch
and it's a memcpy of 8 bytes into 4 byte 'k'.
fortify_memcpy_chk() will hit __write_overflow_field().
That's a build error in i386 and arm allmodconfig.
has_hash is a compile time constant in __htab_map_lookup_elem_u32()
and _u64(), just like key_size.
Only htab_map_gen_lookup() emits them, so the map is BPF_MAP_TYPE_HASH,
never LRU.
Don't read it from htab in these two.
pw-bot: cr
next prev parent reply other threads:[~2026-10-03 6:41 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-02 16:17 [PATCH bpf-next v8 0/2] bpf: htab: Reduce memory use of hash maps T.J. Mercier
2026-10-02 16:17 ` [PATCH bpf-next v8 1/2] bpf: htab: Split htab_elem_lru and htab_elem_pcpu off of htab_elem T.J. Mercier
2026-10-02 16:17 ` [PATCH bpf-next v8 2/2] bpf: htab: Reduce elem_size by 8 bytes for small key sizes T.J. Mercier
2026-10-03 1:33 ` sashiko-bot
2026-10-03 6:41 ` Alexei Starovoitov [this message]
2026-10-03 8:47 ` T.J. Mercier
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=DLUZYDAX6849.KKV543CJGGXH@gmail.com \
--to=alexei.starovoitov@gmail.com \
--cc=andrii@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=emil@etsalapatis.com \
--cc=ihor.solodrai@linux.dev \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.lau@linux.dev \
--cc=memxor@gmail.com \
--cc=mykyta.yatsenko5@gmail.com \
--cc=song@kernel.org \
--cc=tjmercier@google.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.