From: Mykyta Yatsenko <mykyta.yatsenko5@gmail.com>
To: bot+bpf-ci@kernel.org, tjmercier@google.com, ast@kernel.org,
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
Cc: bpf@vger.kernel.org, linux-kernel@vger.kernel.org,
martin.lau@kernel.org, mason@kernel.org
Subject: Re: [PATCH bpf-next v7 1/2] bpf: htab: Split htab_elem_lru and htab_elem_pcpu off of htab_elem
Date: Mon, 28 Sep 2026 19:31:41 +0100 [thread overview]
Message-ID: <1b41e278-f00a-4e25-a319-ba69186d92c9@gmail.com> (raw)
In-Reply-To: <714f119d120fb9ba4aa7e82af621edb7bc97813a760c9dd2cb5363c55b7365a9@mail.kernel.org>
On 9/28/26 4:46 PM, bot+bpf-ci@kernel.org wrote:
>> diff --git a/kernel/bpf/hashtab.c b/kernel/bpf/hashtab.c
>> index 53c99fe4f176..5db11a21ce98 100644
>> --- a/kernel/bpf/hashtab.c
>> +++ b/kernel/bpf/hashtab.c
>
> [ ... ]
>
>> @@ -828,8 +861,12 @@ static __always_inline void *__htab_lru_map_lookup_elem(struct bpf_map *map,
>> struct htab_elem *l = __htab_map_lookup_elem(map, key);
>>
>> if (l) {
>> - if (mark)
>> - bpf_lru_node_set_ref(&l->lru_node);
>> + if (mark) {
>> + struct htab_elem_lru *l_lru =
>> + container_of(l, struct htab_elem_lru, elem);
>> +
>> + bpf_lru_node_set_ref(&l_lru->lru_node);
>> + }
>> return htab_elem_value(l, map->key_size);
>> }
>>
>
> [ ... ]
>
>> @@ -1310,16 +1349,19 @@ static long htab_map_update_elem(struct bpf_map *map, void *key, void *value,
>>
>> static void htab_lru_push_free(struct bpf_htab *htab, struct htab_elem *elem)
>> {
>> + struct htab_elem_lru *l = container_of(elem, struct htab_elem_lru, elem);
>> +
>> check_and_cancel_fields(htab, elem);
>> bpf_map_dec_elem_count(&htab->map);
>> - bpf_lru_push_free(&htab->lru, &elem->lru_node);
>> + bpf_lru_push_free(&htab->lru, &l->lru_node);
>> }
>>
>
> [ ... ]
>
>> @@ -1500,15 +1543,18 @@ static long __htab_lru_percpu_map_update_elem(struct bpf_map *map, void *key,
>> goto err;
>>
>> if (l_old) {
>> - bpf_lru_node_set_ref(&l_old->lru_node);
>> + struct htab_elem_lru *l_old_lru =
>> + container_of(l_old, struct htab_elem_lru, elem);
>> +
>> + bpf_lru_node_set_ref(&l_old_lru->lru_node);
>>
>> /* per-cpu hash map can update value in-place */
>> pcpu_copy_value(htab, htab_elem_get_ptr(l_old, key_size),
>
> [ ... ]
>
>> @@ -2505,7 +2551,10 @@ static void *htab_lru_percpu_map_lookup_elem(struct bpf_map *map, void *key)
>> struct htab_elem *l = __htab_map_lookup_elem(map, key);
>>
>> if (l) {
>> - bpf_lru_node_set_ref(&l->lru_node);
>> + struct htab_elem_lru *l_lru =
>> + container_of(l, struct htab_elem_lru, elem);
>> +
>> + bpf_lru_node_set_ref(&l_lru->lru_node);
>> return this_cpu_ptr(htab_elem_get_ptr(l, map->key_size));
>> }
>>
>> @@ -2521,7 +2570,10 @@ static void *htab_lru_percpu_map_lookup_percpu_elem(struct bpf_map *map, void *k
>>
>> l = __htab_map_lookup_elem(map, key);
>> if (l) {
>> - bpf_lru_node_set_ref(&l->lru_node);
>> + struct htab_elem_lru *l_lru =
>> + container_of(l, struct htab_elem_lru, elem);
>> +
>> + bpf_lru_node_set_ref(&l_lru->lru_node);
>> return per_cpu_ptr(htab_elem_get_ptr(l, map->key_size), cpu);
>> }
>>
>
> This isn't a bug, but would a small helper keep these call sites to one
> line, matching the pcpu accessors this patch adds? Each site now repeats
> the same container_of(l, struct htab_elem_lru, elem) boilerplate followed
> by bpf_lru_node_set_ref(). The patch adds htab_elem_get_ptr_to_pptr() and
> htab_elem_set_ptr_to_pptr() for the pcpu variant, but open-codes the
> container_of for the LRU variant at every site.
>
this sounds like a good refactoring:
static inline void bpf_lru_node_set_ref(struct htab_elem *l)
{
struct htab_elem_lru *l_lru =
container_of(l, struct htab_elem_lru, elem);
if (!READ_ONCE(l_lru.lru_node->ref))
WRITE_ONCE(l_lru.lru_node, 1);
}
>
> ---
> AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
> See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
>
> CI run summary: https://github.com/kernel-patches/bpf/actions/runs/36441357391
next prev parent reply other threads:[~2026-09-28 18:31 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-28 15:01 [PATCH bpf-next v7 0/2] bpf: htab: Reduce memory use of hash maps T.J. Mercier
2026-09-28 15:01 ` [PATCH bpf-next v7 1/2] bpf: htab: Split htab_elem_lru and htab_elem_pcpu off of htab_elem T.J. Mercier
2026-09-28 15:46 ` bot+bpf-ci
2026-09-28 18:31 ` Mykyta Yatsenko [this message]
2026-09-29 16:35 ` T.J. Mercier
2026-10-02 16:07 ` T.J. Mercier
2026-09-28 18:47 ` Mykyta Yatsenko
2026-09-28 15:01 ` [PATCH bpf-next v7 2/2] bpf: htab: Reduce elem_size by 8 bytes for small key sizes T.J. Mercier
2026-09-28 15:18 ` sashiko-bot
2026-09-29 16:36 ` 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=1b41e278-f00a-4e25-a319-ba69186d92c9@gmail.com \
--to=mykyta.yatsenko5@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bot+bpf-ci@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@kernel.org \
--cc=martin.lau@linux.dev \
--cc=mason@kernel.org \
--cc=memxor@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.