On Wed, Feb 3, 2021 at 5:21 PM Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: > > On Wed, Feb 3, 2021 at 6:00 PM Arnaldo Carvalho de Melo <acme@xxxxxxxxxx> wrote: > > > > Em Wed, Feb 03, 2021 at 05:46:48PM -0700, Chris Murphy escreveu: > > > This is just the vmlinuz-5.11.0-0.rc6.141.fc34.x86_64 file > > > > > > https://drive.google.com/file/d/1G_2qLVRIy-ExaJI1-cTqDssrDu3sWo-m/view?usp=sharing > > > > Can you please provide the vmlinux for this file as well? > > Used this > $ /usr/src/kernels/5.11.0-0.rc6.141.fc34.x86_64/scripts/extract-vmlinux > /boot/vmlinuz-5.11.0-0.rc6.141.fc34.x86_64 > vmlinux > > https://drive.google.com/file/d/1h6cC9oZ16oLbR6NyPqKkVGaoUQ2u1UQz/view?usp=sharing > > I recompiled with gcc 10.2.1 and I'm not having these problems, so it > might be that. > sched_reset_on_fork is a bitfield in task_struct. You don't see issue on gcc 10.2, but see it on gcc 11. GCC 11 started emitting DWARF5 by default, right? It's something that Arnaldo probably already fixed in the latest pahole. Could you please try to build pahole from sources and see if you run into the same problem again? Verifier is catching a real issue with offsets going backwards. Here's excerpt from BTF dump of task_struct: 'pdeath_signal' type_id=17 bits_offset=18048 'jobctl' type_id=1 bits_offset=18112 'personality' type_id=6 bits_offset=18176 'sched_reset_on_fork' type_id=6 bits_offset=0 'sched_contributes_to_load' type_id=6 bits_offset=0 'sched_migrated' type_id=6 bits_offset=0 'sched_psi_wake_requeue' type_id=6 bits_offset=0 ... eventually we get to non-bitfield field 'atomic_flags' type_id=1 bits_offset=18304 So it's a bitfield offset breakage that should be fixed in pahole 1.20. > > > -- > Chris Murphy
