[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <883a21af-750c-49df-88c6-47bd642e03d4@linux.dev>
Date: Fri, 2 Jan 2026 23:38:25 +0800
From: Leon Hwang <leon.hwang@...ux.dev>
To: bot+bpf-ci@...nel.org, bpf@...r.kernel.org
Cc: ast@...nel.org, daniel@...earbox.net, andrii@...nel.org,
martin.lau@...ux.dev, eddyz87@...il.com, song@...nel.org,
yonghong.song@...ux.dev, john.fastabend@...il.com, kpsingh@...nel.org,
sdf@...ichev.me, haoluo@...gle.com, jolsa@...nel.org, puranjay@...nel.org,
xukuohai@...weicloud.com, catalin.marinas@....com, will@...nel.org,
davem@...emloft.net, dsahern@...nel.org, tglx@...utronix.de,
mingo@...hat.com, bp@...en8.de, dave.hansen@...ux.intel.com, x86@...nel.org,
hpa@...or.com, akpm@...ux-foundation.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
netdev@...r.kernel.org, kernel-patches-bot@...com, martin.lau@...nel.org,
clm@...a.com, ihor.solodrai@...ux.dev
Subject: Re: [PATCH bpf-next 1/4] bpf: tailcall: Introduce
bpf_arch_tail_call_prologue_offset
On 2026/1/2 23:21, bot+bpf-ci@...nel.org wrote:
>> diff --git a/kernel/bpf/arraymap.c b/kernel/bpf/arraymap.c
>> index 1eeb31c5b317..beedd1281c22 100644
>> --- a/kernel/bpf/arraymap.c
>> +++ b/kernel/bpf/arraymap.c
>> @@ -127,6 +127,9 @@ static struct bpf_map *array_map_alloc(union bpf_attr *attr)
>> array_size += (u64) max_entries * elem_size;
>> }
>> }
>> + if (attr->map_type == BPF_MAP_TYPE_PROG_ARRAY && bpf_arch_tail_call_prologue_offset())
>> + /* Store tailcall targets */
>> + array_size += (u64) max_entries * sizeof(void *);
>
> Should array_map_mem_usage() also account for this additional space?
> Currently array_map_mem_usage() handles special cases for percpu arrays
> and mmapable arrays, but has no corresponding check for PROG_ARRAY maps
> when bpf_arch_tail_call_prologue_offset() is non-zero. This would cause
> the reported memory usage to be lower than the actual allocation when
> an architecture implements this function (e.g., x86_64 and arm64 in the
> subsequent patches of this series).
>
> [ ... ]
>
You are right, array_map_mem_usage() needs to stay in sync with the
allocation logic to avoid under-reporting memory.
I will include this fix in the next revision after I’ve collected more
feedback.
Thanks,
Leon
Powered by blists - more mailing lists