On 7/8/24 10:20 AM, Linux regression tracking (Thorsten Leemhuis) wrote:
> [CCing the regressions list and people mentioned below]
>
> On 12.06.24 16:53, Alexei Starovoitov wrote:
>> On Wed, Jun 12, 2024 at 2:51 AM Mohammad Shehar Yaar Tausif
>> <sheharyaar48@xxxxxxxxx> wrote:
>>>
>>> The original function call passed size of smap->bucket before the number of
>>> buckets which raises the error 'calloc-transposed-args' on compilation.
>>>
>>> Fixes: 62827d612ae5 ("bpf: Remove __bpf_local_storage_map_alloc")
>>> Reviewed-by: Andrii Nakryiko <andrii@xxxxxxxxxx>
>>> Signed-off-by: Mohammad Shehar Yaar Tausif <sheharyaar48@xxxxxxxxx>
>>> ---
>>> - already merged in linux-next
>>> - [1] suggested sending as a fix for 6.10 cycle
>>
>> No. It's not a fix.
>
> If you have a minute, could you please explain why that is? From what I
> can see a quite a few people run into build problems with 6.10-rc
> recently that are fixed by the patch:
>
> * Péter Ujfalusi
> https://lore.kernel.org/bpf/363ad8d1-a2d2-4fca-b66a-3d838eb5def9@xxxxxxxxx/
>
> * Christian Kujau
> https://lore.kernel.org/bpf/48360912-b239-51f2-8f25-07a46516dc76@xxxxxxxxxxxxxxx/
> https://lore.kernel.org/lkml/d0dd2457-ab58-1b08-caa4-93eaa2de221e@xxxxxxxxxxxxxxx/
>
> * Lorenzo Stoakes
> https://fosstodon.org/@ljs@xxxxxxxxxxxxxxxxx/112734050799590482
>
> At the same time I see that the culprit mentioned above is from 6.4-rc1,
IIUC the order was wrong even before, but see below.
> so I guess it there must be some other reason why a few people seem to
> tun into this now. Did some other change expose this problem? Or are
> updated compilers causing this?
I think it's because of 2c321f3f70bc ("mm: change inlined allocation helpers
to account at the call site"), which was added in 6.10-rc1 and thus makes
this technically a 6.10 regression after all. So what triggers the bug is
AFAICS the following together:
- gcc-14 (didn't see it with gcc-13)
- commit 2c321f3f70bc that makes bpf_map_kvcalloc a macro that does
kvcalloc() directly instead of static inline function wrapping it for
!CONFIG_MEMCG
- CONFIG_MEMCG=n in .config
The fix is so trivial, it's better to include it in 6.10 even this late.
> Ciao, Thorsten
>
>>> [1] https://lore.kernel.org/all/363ad8d1-a2d2-4fca-b66a-3d838eb5def9@xxxxxxxxx/
>>> ---
>>> kernel/bpf/bpf_local_storage.c | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/kernel/bpf/bpf_local_storage.c b/kernel/bpf/bpf_local_storage.c
>>> index 976cb258a0ed..c938dea5ddbf 100644
>>> --- a/kernel/bpf/bpf_local_storage.c
>>> +++ b/kernel/bpf/bpf_local_storage.c
>>> @@ -782,8 +782,8 @@ bpf_local_storage_map_alloc(union bpf_attr *attr,
>>> nbuckets = max_t(u32, 2, nbuckets);
>>> smap->bucket_log = ilog2(nbuckets);
>>>
>>> - smap->buckets = bpf_map_kvcalloc(&smap->map, sizeof(*smap->buckets),
>>> - nbuckets, GFP_USER | __GFP_NOWARN);
>>> + smap->buckets = bpf_map_kvcalloc(&smap->map, nbuckets,
>>> + sizeof(*smap->buckets), GFP_USER | __GFP_NOWARN);
>>> if (!smap->buckets) {
>>> err = -ENOMEM;
>>> goto free_smap;
>>>
>>> ---
>>> base-commit: 2ef5971ff345d3c000873725db555085e0131961
>>> change-id: 20240612-master-fe9e63ab5c95
>>>
>>> Best regards,
>>> --
>>> Mohammad Shehar Yaar Tausif <sheharyaar48@xxxxxxxxx>
>>>
