linux-kernel - Re: [PATCH] fix linux kernel BTF builds: increase max percpu variables by 10x

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Thu, 29 Feb 2024 09:17:44 +0000
From: Alan Maguire <alan.maguire@...cle.com>
To: John Hubbard <jhubbard@...dia.com>, Jiri Olsa <olsajiri@...il.com>
Cc: Arnaldo Carvalho de Melo <acme@...hat.com>,
        Alexei Starovoitov <ast@...nel.org>, bpf@...r.kernel.org,
        LKML <linux-kernel@...r.kernel.org>, dwarves@...r.kernel.org
Subject: Re: [PATCH] fix linux kernel BTF builds: increase max percpu
 variables by 10x

On 28/02/2024 23:21, John Hubbard wrote:
> On 2/28/24 04:04, Alan Maguire wrote:
>> On 28/02/2024 09:20, Jiri Olsa wrote:
>>> On Tue, Feb 27, 2024 at 07:21:42PM -0800, John Hubbard wrote:
> ...
>>> do you have an actual count of percpu variables for your config?
> 
> That's a very reasonable question...
> 
>>> 10x seems a lot to me
> 
> Me too. This was a "make the problem go away now please" type of "fix". :)
> 


Running

bpftool btf dump file vmlinux |grep "] VAR"

..should give us a sense of what's going on. I only see 375 per-cpu
variables when I do this so maybe there's something
kernel-config-specific that might explain why you have so many more?

>>>
>>> this might be a workaround, but we should make encoder->percpu.vars
>>> dynamically allocated like we do for functions
> 
> Yes, that's a much better design imho.
> 
>>>
>>> jirka
>>>
>>
>> Good idea Jiri; John would you mind trying the attached patch? Thanks!
> 
> It works perfectly for me. For that patch, please feel free to add:
> 
> Tested-by: John Hubbard <jhubbard@...dia.com>
>


that's great, thanks for testing this John!

Alan

> 
> thanks,