On Fri, Aug 26, 2022 at 09:51:54AM -0700, Yonghong Song wrote: > > > On 8/26/22 6:52 AM, Jiri Olsa wrote: > > On Fri, Aug 26, 2022 at 05:59:44AM +0300, Vitaly Chikunov wrote: > > > On Fri, Aug 26, 2022 at 05:52:20AM +0300, Vitaly Chikunov wrote: > > > > Arnaldo, > > > > > > > > On Thu, Aug 25, 2022 at 08:16:20PM +0300, Vitaly Chikunov wrote: > > > > > On Thu, Aug 25, 2022 at 01:47:59PM -0300, Arnaldo Carvalho de Melo wrote: > > > > > > On Thu, Aug 25, 2022, 1:35 PM Vitaly Chikunov <vt@xxxxxxxxxxxx> wrote: > > > > > > > > > > > > > > I also noticed that after upgrading pahole to v1.24 kernel build (tested on > > > > > > > v5.18.19, v5.15.63, sorry for not testing on mainline) fails with: > > > > > > > > > > > > > > BTFIDS vmlinux > > > > > > > + ./tools/bpf/resolve_btfids/resolve_btfids vmlinux > > > > > > > FAILED: load BTF from vmlinux: Invalid argument > > > > > > > > > > > > > > Perhaps, .tmp_vmlinux.btf is generated incorrectly? Downgrading dwarves to > > > > > > > v1.23 resolves the issue. > > > > > > > > > > > > > > > > > > > Can you try this, from Martin Reboredo (Archlinux): > > > > > > > > > > > > Can you try a build of the kernel or the by passing the > > > > > > --skip_encoding_btf_enum64 to scripts/pahole-flags.sh? > > > > > > > > > > > > Here's a patch for either in tree scripts/pahole-flags.sh or > > > > > > /usr/lib/modules/5.19.3-arch1-1/build/scripts/pahole-flags.sh > > > > > > > > > > This patch helped and kernel builds successfully after applying it. > > > > > (Didn't notice this suggestion in release discussion thread.) > > > > > > > > Even thought it now compiles with this patch, it does not boot > > > > afterwards (in virtme-like env), witch such console messages: > > > > > > I'm talking here about 5.15.62. Yes, proposed patch does not apply there > > > (since there is no `scripts/pahole-flags.sh`), but I updated > > > `scripts/link-vmlinux.sh` with the similar `if` to append > > > `--skip_encoding_btf_enum64` which lets then compilation pass. > > > > > > Thanks, > > > > > > > > > > > [ 0.767649] Run /init as init process > > > > [ 0.770858] BPF:[593] ENUM perf_event_task_context > > > > [ 0.771262] BPF:size=4 vlen=4 > > > > [ 0.771511] BPF: > > > > [ 0.771680] BPF:Invalid btf_info kind_flag > > > > [ 0.772016] BPF: > > > > I can see the same on 5.15, it looks like the libbpf change that > > pahole is compiled with is setting the type's kflag for values < 0: > > (which is the case for perf_event_task_context enum first value) > > > > dffbbdc2d988 libbpf: Add enum64 parsing and new enum64 public API > > > > but IIUC kflag should stay zero for normal enum otherwise the btf meta > > verifier screams > > This is deliberate so we can have sign bit set properly for 32bit enum. > To avoid this behavior, the correct way is to turn off enum64 support > in pahole with flag --skip_encoding_btf_enum64. I used that as well, it wouldn't compile without the error is during the boot where the standard enum has kflag set jirka > > > > > if I compile pahole with the libbpf change below I can boot 5.15 kernel > > normally > > > > Yonghong, any idea? > > > > thanks, > > jirka > > > > > > --- > > diff --git a/src/btf.c b/src/btf.c > > index 2d14f1a52d7a..53d7516e4b89 100644 > > --- a/src/btf.c > > +++ b/src/btf.c > > @@ -2151,10 +2151,6 @@ int btf__add_enum_value(struct btf *btf, const char *name, __s64 value) > > t = btf_last_type(btf); > > btf_type_inc_vlen(t); > > - /* if negative value, set signedness to signed */ > > - if (value < 0) > > - t->info = btf_type_info(btf_kind(t), btf_vlen(t), true); > > - > > btf->hdr->type_len += sz; > > btf->hdr->str_off += sz; > > return 0;
