Em Wed, Feb 01, 2023 at 07:32:04PM -0300, Arnaldo Carvalho de Melo escreveu: > Em Wed, Feb 01, 2023 at 02:01:47PM -0300, Arnaldo Carvalho de Melo escreveu: > > Em Wed, Feb 01, 2023 at 08:49:07AM -0800, Alexei Starovoitov escreveu: > > > > Great, so inline and __used with __bpf_kfunc sounds like the way forward > > > > in the short term. Arnaldo / Alexei -- how do you want to resolve the > > > > dependency here? Going through bpf-next is probably a good idea so that > > > > we get proper CI coverage, and any kfuncs added to bpf-next after this > > > > can use the macro. Does that work for you? > > > > > > It feels fixed pahole should be done under some flag > > > otherwise when people update the pahole the existing and older > > > kernels might stop building with warns: > > > WARN: resolve_btfids: unresolved symbol bpf_xdp_metadata_rx_hash > > > WARN: resolve_btfids: unresolved symbol bpf_task_kptr_get > > > ... > > > > > > Arnaldo, could you check what warns do you see with this fixed pahole > > > in bpf tree ? > > > > Sure. > > These appeared on a distro like .config: > > BTFIDS vmlinux > WARN: resolve_btfids: unresolved symbol bpf_xdp_metadata_rx_hash > WARN: resolve_btfids: unresolved symbol bpf_task_kptr_get > WARN: resolve_btfids: unresolved symbol bpf_cpumask_any > WARN: resolve_btfids: unresolved symbol bpf_ct_change_status > > I'll do it with allmodconfig ^C[1]+ Done nohup make -j32 O=../build/allmodconfig ⬢[acme@toolbox bpf-next]$ ⬢[acme@toolbox bpf-next]$ grep "^WARN: resolve_btfids: " nohup.out WARN: resolve_btfids: unresolved symbol bpf_xdp_metadata_rx_hash WARN: resolve_btfids: unresolved symbol bpf_task_kptr_get WARN: resolve_btfids: unresolved symbol bpf_cpumask_any WARN: resolve_btfids: unresolved symbol bpf_ct_change_status ⬢[acme@toolbox bpf-next]$
