On Mon, Dec 9, 2024 at 3:33 PM Arnaldo Carvalho de Melo
<arnaldo.melo@xxxxxxxxx> wrote:
>
> On Mon, Dec 9, 2024, 8:00 PM Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> wrote:
>>
>> On Mon, Dec 9, 2024 at 12:23 PM Arnaldo Carvalho de Melo
>> <acme@xxxxxxxxxx> wrote:
>>
>> > and additionally the type is not like the one you added to the barebones
>> > vmlinux.h:
>>
>> > ⬢ [acme@toolbox perf-tools-next]$ git show d82e2e170d1c756b | grep 'struct bpf_iter__kmem_cache {' -A3
>> > +struct bpf_iter__kmem_cache {
>> > + struct kmem_cache *s;
>> > +} __attribute__((preserve_access_index));
>> > +
>> > ⬢ [acme@toolbox perf-tools-next]$
>>
>> > But:
>>
>> > ⬢ [acme@toolbox perf-tools-next]$ uname -a
>> > Linux toolbox 6.13.0-rc2 #1 SMP PREEMPT_DYNAMIC Mon Dec 9 12:33:35 -03 2024 x86_64 GNU/Linux
>> > ⬢ [acme@toolbox perf-tools-next]$ pahole bpf_iter__kmem_cache
>> > struct bpf_iter__kmem_cache {
>> > union {
>> > struct bpf_iter_meta * meta; /* 0 8 */
>> > }; /* 0 8 */
>> > union {
>> > struct kmem_cache * s; /* 8 8 */
>> > }; /* 8 8 */
>> >
>> > /* size: 16, cachelines: 1, members: 2 */
>> > /* last cacheline: 16 bytes */
>> > };
>>
>> > ⬢ [acme@toolbox perf-tools-next]$
>>
>> > Do CO-RE handle this?
>>
>> I don't know exactly what the problem you are running into is, but
>> yes, BPF CO-RE allows handling missing fields, incompatible field type
>> changes, field renames, etc. All without having to break a
>> compilation. See [0] (and one subsection after that) for
>> "documentation" and examples.
>>
>> [0] https://nakryiko.com/posts/bpf-core-reference-guide/#defining-own-co-re-relocatable-type-definitions
>
>
>>
> The doubt is the extra layer of unnamed unions in the BTF for the kernel that's not present in the minimal representation shipped with perf.
anonymous unions or structs are transparent to BPF CO-RE relocation,
so that shouldn't be a problem
>
> - Arnaldo
