All of lore.kernel.org
 help / color / mirror / Atom feed
* CORE feature request: support checking field type directly
@ 2023-01-12 22:18 Hao Luo
  2023-01-13 23:41 ` Andrii Nakryiko
  2023-01-17 21:56 ` Daniel Müller
  0 siblings, 2 replies; 13+ messages in thread
From: Hao Luo @ 2023-01-12 22:18 UTC (permalink / raw)
  To: bpf
  Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
	Martin KaFai Lau, Song Liu, Yonghong Song, KP Singh,
	Stanislav Fomichev, Jiri Olsa, John Fastabend

Hi all,

Feature request:

To support checking the type of a specific field directly.

Background:

Currently, As far as I know, CORE is able to check a field’s
existence, offset, size and signedness, but not the field’s type
directly.

There are changes that convert a field from a scalar type to a struct
type, without changing the field’s name, offset or size. In that case,
it is currently difficult to use CORE to check such changes. For a
concrete example,

Commit 94a9717b3c (“locking/rwsem: Make rwsem->owner an atomic_long_t”)

Changed the type of rw_semaphore::owner from tast_struct * to
atomic_long_t. In that change, the field name, offset and size remain
the same. But the BPF program code used to extract the value is
different. For the kernel where the field is a pointer, we can write:

sem->owner

While in the kernel where the field is an atomic, we need to write:

sem->owner.counter.

It would be great to be able to check a field’s type directly.
Probably something like:

#include “vmlinux.h”

struct rw_semaphore__old {
        struct task_struct *owner;
};

struct rw_semaphore__new {
        atomic_long_t owner;
};

u64 owner;
if (bpf_core_field_type_is(sem->owner, struct task_struct *)) {
        struct rw_semaphore__old *old = (struct rw_semaphore__old *)sem;
        owner = (u64)sem->owner;
} else if (bpf_core_field_type_is(sem->owner, atomic_long_t)) {
        struct rw_semaphore__new *new = (struct rw_semaphore__new *)sem;
        owner = new->owner.counter;
}

Hao

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: CORE feature request: support checking field type directly
  2023-01-12 22:18 CORE feature request: support checking field type directly Hao Luo
@ 2023-01-13 23:41 ` Andrii Nakryiko
  2023-01-14  1:06   ` Hao Luo
  2023-01-17 21:56 ` Daniel Müller
  1 sibling, 1 reply; 13+ messages in thread
From: Andrii Nakryiko @ 2023-01-13 23:41 UTC (permalink / raw)
  To: Hao Luo
  Cc: bpf, Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
	Martin KaFai Lau, Song Liu, Yonghong Song, KP Singh,
	Stanislav Fomichev, Jiri Olsa, John Fastabend

On Thu, Jan 12, 2023 at 2:18 PM Hao Luo <haoluo@google.com> wrote:
>
> Hi all,
>
> Feature request:
>
> To support checking the type of a specific field directly.
>
> Background:
>
> Currently, As far as I know, CORE is able to check a field’s
> existence, offset, size and signedness, but not the field’s type
> directly.
>
> There are changes that convert a field from a scalar type to a struct
> type, without changing the field’s name, offset or size. In that case,
> it is currently difficult to use CORE to check such changes. For a
> concrete example,
>
> Commit 94a9717b3c (“locking/rwsem: Make rwsem->owner an atomic_long_t”)
>
> Changed the type of rw_semaphore::owner from tast_struct * to
> atomic_long_t. In that change, the field name, offset and size remain
> the same. But the BPF program code used to extract the value is
> different. For the kernel where the field is a pointer, we can write:
>
> sem->owner
>
> While in the kernel where the field is an atomic, we need to write:
>
> sem->owner.counter.
>
> It would be great to be able to check a field’s type directly.
> Probably something like:
>
> #include “vmlinux.h”
>
> struct rw_semaphore__old {
>         struct task_struct *owner;
> };
>
> struct rw_semaphore__new {
>         atomic_long_t owner;
> };
>
> u64 owner;
> if (bpf_core_field_type_is(sem->owner, struct task_struct *)) {
>         struct rw_semaphore__old *old = (struct rw_semaphore__old *)sem;
>         owner = (u64)sem->owner;
> } else if (bpf_core_field_type_is(sem->owner, atomic_long_t)) {
>         struct rw_semaphore__new *new = (struct rw_semaphore__new *)sem;
>         owner = new->owner.counter;
> }
>

Have you tried bpf_core_type_matches()? It seems like exactly what you
are looking for? See [0] for logic of what constitutes "a match".

  [0] https://github.com/libbpf/libbpf/blob/master/src/relo_core.c#L1517-L1543

> Hao

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: CORE feature request: support checking field type directly
  2023-01-13 23:41 ` Andrii Nakryiko
@ 2023-01-14  1:06   ` Hao Luo
  2023-01-14  1:14     ` Andrii Nakryiko
  0 siblings, 1 reply; 13+ messages in thread
From: Hao Luo @ 2023-01-14  1:06 UTC (permalink / raw)
  To: Andrii Nakryiko
  Cc: bpf, Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
	Martin KaFai Lau, Song Liu, Yonghong Song, KP Singh,
	Stanislav Fomichev, Jiri Olsa, John Fastabend

On Fri, Jan 13, 2023 at 3:41 PM Andrii Nakryiko
<andrii.nakryiko@gmail.com> wrote:
>
> On Thu, Jan 12, 2023 at 2:18 PM Hao Luo <haoluo@google.com> wrote:
> >
> > Hi all,
> >
> > Feature request:
> >
> > To support checking the type of a specific field directly.
> >
> > Background:
> >
> > Currently, As far as I know, CORE is able to check a field’s
> > existence, offset, size and signedness, but not the field’s type
> > directly.
> >
> > There are changes that convert a field from a scalar type to a struct
> > type, without changing the field’s name, offset or size. In that case,
> > it is currently difficult to use CORE to check such changes. For a
> > concrete example,
> >
> > Commit 94a9717b3c (“locking/rwsem: Make rwsem->owner an atomic_long_t”)
> >
> > Changed the type of rw_semaphore::owner from tast_struct * to
> > atomic_long_t. In that change, the field name, offset and size remain
> > the same. But the BPF program code used to extract the value is
> > different. For the kernel where the field is a pointer, we can write:
> >
> > sem->owner
> >
> > While in the kernel where the field is an atomic, we need to write:
> >
> > sem->owner.counter.
> >
> > It would be great to be able to check a field’s type directly.
> > Probably something like:
> >
> > #include “vmlinux.h”
> >
> > struct rw_semaphore__old {
> >         struct task_struct *owner;
> > };
> >
> > struct rw_semaphore__new {
> >         atomic_long_t owner;
> > };
> >
> > u64 owner;
> > if (bpf_core_field_type_is(sem->owner, struct task_struct *)) {
> >         struct rw_semaphore__old *old = (struct rw_semaphore__old *)sem;
> >         owner = (u64)sem->owner;
> > } else if (bpf_core_field_type_is(sem->owner, atomic_long_t)) {
> >         struct rw_semaphore__new *new = (struct rw_semaphore__new *)sem;
> >         owner = new->owner.counter;
> > }
> >
>
> Have you tried bpf_core_type_matches()? It seems like exactly what you
> are looking for? See [0] for logic of what constitutes "a match".
>

It seems bpf_core_type_matches() is for the userspace code. I'm
looking for type checking in the BPF code. We probably don't need to
check type equivalence, just comparing the btf_id of the field's type
and the btf_id of a target type may be sufficient.

The commit 94a9717b3c (“locking/rwsem: Make rwsem->owner an
atomic_long_t”) is rare, but the 'owner' field is useful for tracking
the owner of a kernel lock.

>   [0] https://github.com/libbpf/libbpf/blob/master/src/relo_core.c#L1517-L1543
>
> > Hao

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: CORE feature request: support checking field type directly
  2023-01-14  1:06   ` Hao Luo
@ 2023-01-14  1:14     ` Andrii Nakryiko
  2023-01-14  2:19       ` Hao Luo
  0 siblings, 1 reply; 13+ messages in thread
From: Andrii Nakryiko @ 2023-01-14  1:14 UTC (permalink / raw)
  To: Hao Luo
  Cc: bpf, Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
	Martin KaFai Lau, Song Liu, Yonghong Song, KP Singh,
	Stanislav Fomichev, Jiri Olsa, John Fastabend

On Fri, Jan 13, 2023 at 5:06 PM Hao Luo <haoluo@google.com> wrote:
>
> On Fri, Jan 13, 2023 at 3:41 PM Andrii Nakryiko
> <andrii.nakryiko@gmail.com> wrote:
> >
> > On Thu, Jan 12, 2023 at 2:18 PM Hao Luo <haoluo@google.com> wrote:
> > >
> > > Hi all,
> > >
> > > Feature request:
> > >
> > > To support checking the type of a specific field directly.
> > >
> > > Background:
> > >
> > > Currently, As far as I know, CORE is able to check a field’s
> > > existence, offset, size and signedness, but not the field’s type
> > > directly.
> > >
> > > There are changes that convert a field from a scalar type to a struct
> > > type, without changing the field’s name, offset or size. In that case,
> > > it is currently difficult to use CORE to check such changes. For a
> > > concrete example,
> > >
> > > Commit 94a9717b3c (“locking/rwsem: Make rwsem->owner an atomic_long_t”)
> > >
> > > Changed the type of rw_semaphore::owner from tast_struct * to
> > > atomic_long_t. In that change, the field name, offset and size remain
> > > the same. But the BPF program code used to extract the value is
> > > different. For the kernel where the field is a pointer, we can write:
> > >
> > > sem->owner
> > >
> > > While in the kernel where the field is an atomic, we need to write:
> > >
> > > sem->owner.counter.
> > >
> > > It would be great to be able to check a field’s type directly.
> > > Probably something like:
> > >
> > > #include “vmlinux.h”
> > >
> > > struct rw_semaphore__old {
> > >         struct task_struct *owner;
> > > };
> > >
> > > struct rw_semaphore__new {
> > >         atomic_long_t owner;
> > > };
> > >
> > > u64 owner;
> > > if (bpf_core_field_type_is(sem->owner, struct task_struct *)) {
> > >         struct rw_semaphore__old *old = (struct rw_semaphore__old *)sem;
> > >         owner = (u64)sem->owner;
> > > } else if (bpf_core_field_type_is(sem->owner, atomic_long_t)) {
> > >         struct rw_semaphore__new *new = (struct rw_semaphore__new *)sem;
> > >         owner = new->owner.counter;
> > > }
> > >
> >
> > Have you tried bpf_core_type_matches()? It seems like exactly what you
> > are looking for? See [0] for logic of what constitutes "a match".
> >
>
> It seems bpf_core_type_matches() is for the userspace code. I'm

It's in the same family as bpf_type_{exists,size}() and
bpf_field_{exists,size,offset}(). It's purely BPF-side. Please grep
for bpf_core_type_matches() in selftests/bpf.

> looking for type checking in the BPF code. We probably don't need to
> check type equivalence, just comparing the btf_id of the field's type
> and the btf_id of a target type may be sufficient.

With the example above something like below should work:

struct rw_semaphore__old {
        struct task_struct *owner;
};

struct rw_semaphore__new {
        atomic_long_t owner;
};

u64 owner;
if (bpf_core_type_matches(struct rw_semaphore__old) /* owner is
task_struct pointer */) {
        struct rw_semaphore__old *old = (struct rw_semaphore__old *)sem;
        owner = (u64)sem->owner;
} else if (bpf_core_type_matches(struct rw_semaphore__old) /* owner
field is atomic_long_t */) {
        struct rw_semaphore__new *new = (struct rw_semaphore__new *)sem;
        owner = new->owner.counter;
}

>
> The commit 94a9717b3c (“locking/rwsem: Make rwsem->owner an
> atomic_long_t”) is rare, but the 'owner' field is useful for tracking
> the owner of a kernel lock.

We implemented bpf_core_type_matches() to detect tracepoint changes,
which is equivalent (if not harder) use case. Give it a try.

>
> >   [0] https://github.com/libbpf/libbpf/blob/master/src/relo_core.c#L1517-L1543
> >
> > > Hao

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: CORE feature request: support checking field type directly
  2023-01-14  1:14     ` Andrii Nakryiko
@ 2023-01-14  2:19       ` Hao Luo
  2023-01-14  2:44         ` Andrii Nakryiko
  0 siblings, 1 reply; 13+ messages in thread
From: Hao Luo @ 2023-01-14  2:19 UTC (permalink / raw)
  To: Andrii Nakryiko
  Cc: bpf, Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
	Martin KaFai Lau, Song Liu, Yonghong Song, KP Singh,
	Stanislav Fomichev, Jiri Olsa, John Fastabend

On Fri, Jan 13, 2023 at 5:14 PM Andrii Nakryiko
<andrii.nakryiko@gmail.com> wrote:
>
> On Fri, Jan 13, 2023 at 5:06 PM Hao Luo <haoluo@google.com> wrote:
> >
> > On Fri, Jan 13, 2023 at 3:41 PM Andrii Nakryiko
> > <andrii.nakryiko@gmail.com> wrote:
> > >
<...>
> > >
> > > Have you tried bpf_core_type_matches()? It seems like exactly what you
> > > are looking for? See [0] for logic of what constitutes "a match".
> > >
> >
> > It seems bpf_core_type_matches() is for the userspace code. I'm
>
> It's in the same family as bpf_type_{exists,size}() and
> bpf_field_{exists,size,offset}(). It's purely BPF-side. Please grep
> for bpf_core_type_matches() in selftests/bpf.
>
> > looking for type checking in the BPF code. We probably don't need to
> > check type equivalence, just comparing the btf_id of the field's type
> > and the btf_id of a target type may be sufficient.
>
> With the example above something like below should work:
>
> struct rw_semaphore__old {
>         struct task_struct *owner;
> };
>
> struct rw_semaphore__new {
>         atomic_long_t owner;
> };
>
> u64 owner;
> if (bpf_core_type_matches(struct rw_semaphore__old) /* owner is
> task_struct pointer */) {
>         struct rw_semaphore__old *old = (struct rw_semaphore__old *)sem;
>         owner = (u64)sem->owner;
> } else if (bpf_core_type_matches(struct rw_semaphore__old) /* owner
> field is atomic_long_t */) {
>         struct rw_semaphore__new *new = (struct rw_semaphore__new *)sem;
>         owner = new->owner.counter;
> }
>
> >
> > The commit 94a9717b3c (“locking/rwsem: Make rwsem->owner an
> > atomic_long_t”) is rare, but the 'owner' field is useful for tracking
> > the owner of a kernel lock.
>
> We implemented bpf_core_type_matches() to detect tracepoint changes,
> which is equivalent (if not harder) use case. Give it a try.
>

Thanks Andrii for the pointer. It's still not working. I got the
following error when loading:

libbpf: prog 'on_contention_begin': relo #1: parsing [43] struct
rw_semaphore__old + 0 failed: -22
libbpf: prog 'on_contention_begin': relo #1: failed to relocate: -22
libbpf: failed to perform CO-RE relocations: -22

I'll dig a little more next week.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: CORE feature request: support checking field type directly
  2023-01-14  2:19       ` Hao Luo
@ 2023-01-14  2:44         ` Andrii Nakryiko
  2023-01-17 18:45           ` Hao Luo
  0 siblings, 1 reply; 13+ messages in thread
From: Andrii Nakryiko @ 2023-01-14  2:44 UTC (permalink / raw)
  To: Hao Luo
  Cc: bpf, Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
	Martin KaFai Lau, Song Liu, Yonghong Song, KP Singh,
	Stanislav Fomichev, Jiri Olsa, John Fastabend

On Fri, Jan 13, 2023 at 6:20 PM Hao Luo <haoluo@google.com> wrote:
>
> On Fri, Jan 13, 2023 at 5:14 PM Andrii Nakryiko
> <andrii.nakryiko@gmail.com> wrote:
> >
> > On Fri, Jan 13, 2023 at 5:06 PM Hao Luo <haoluo@google.com> wrote:
> > >
> > > On Fri, Jan 13, 2023 at 3:41 PM Andrii Nakryiko
> > > <andrii.nakryiko@gmail.com> wrote:
> > > >
> <...>
> > > >
> > > > Have you tried bpf_core_type_matches()? It seems like exactly what you
> > > > are looking for? See [0] for logic of what constitutes "a match".
> > > >
> > >
> > > It seems bpf_core_type_matches() is for the userspace code. I'm
> >
> > It's in the same family as bpf_type_{exists,size}() and
> > bpf_field_{exists,size,offset}(). It's purely BPF-side. Please grep
> > for bpf_core_type_matches() in selftests/bpf.
> >
> > > looking for type checking in the BPF code. We probably don't need to
> > > check type equivalence, just comparing the btf_id of the field's type
> > > and the btf_id of a target type may be sufficient.
> >
> > With the example above something like below should work:
> >
> > struct rw_semaphore__old {
> >         struct task_struct *owner;
> > };
> >
> > struct rw_semaphore__new {
> >         atomic_long_t owner;
> > };
> >
> > u64 owner;
> > if (bpf_core_type_matches(struct rw_semaphore__old) /* owner is
> > task_struct pointer */) {
> >         struct rw_semaphore__old *old = (struct rw_semaphore__old *)sem;
> >         owner = (u64)sem->owner;
> > } else if (bpf_core_type_matches(struct rw_semaphore__old) /* owner
> > field is atomic_long_t */) {
> >         struct rw_semaphore__new *new = (struct rw_semaphore__new *)sem;
> >         owner = new->owner.counter;
> > }
> >
> > >
> > > The commit 94a9717b3c (“locking/rwsem: Make rwsem->owner an
> > > atomic_long_t”) is rare, but the 'owner' field is useful for tracking
> > > the owner of a kernel lock.
> >
> > We implemented bpf_core_type_matches() to detect tracepoint changes,
> > which is equivalent (if not harder) use case. Give it a try.
> >
>
> Thanks Andrii for the pointer. It's still not working. I got the
> following error when loading:
>
> libbpf: prog 'on_contention_begin': relo #1: parsing [43] struct
> rw_semaphore__old + 0 failed: -22
> libbpf: prog 'on_contention_begin': relo #1: failed to relocate: -22
> libbpf: failed to perform CO-RE relocations: -22
>
> I'll dig a little more next week.

You need triple underscore between old and new suffixes, see [0] for
ignored suffix rule.

  [0] https://nakryiko.com/posts/bpf-core-reference-guide/#handling-incompatible-field-and-type-changes

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: CORE feature request: support checking field type directly
  2023-01-14  2:44         ` Andrii Nakryiko
@ 2023-01-17 18:45           ` Hao Luo
  0 siblings, 0 replies; 13+ messages in thread
From: Hao Luo @ 2023-01-17 18:45 UTC (permalink / raw)
  To: Andrii Nakryiko
  Cc: bpf, Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
	Martin KaFai Lau, Song Liu, Yonghong Song, KP Singh,
	Stanislav Fomichev, Jiri Olsa, John Fastabend

On Fri, Jan 13, 2023 at 6:44 PM Andrii Nakryiko
<andrii.nakryiko@gmail.com> wrote:
>
<...>
> You need triple underscore between old and new suffixes, see [0] for
> ignored suffix rule.
>
>   [0] https://nakryiko.com/posts/bpf-core-reference-guide/#handling-incompatible-field-and-type-changes

Triple underscore works!

Thanks!
Hao

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: CORE feature request: support checking field type directly
  2023-01-12 22:18 CORE feature request: support checking field type directly Hao Luo
  2023-01-13 23:41 ` Andrii Nakryiko
@ 2023-01-17 21:56 ` Daniel Müller
  2023-01-17 22:21   ` Daniel Müller
  1 sibling, 1 reply; 13+ messages in thread
From: Daniel Müller @ 2023-01-17 21:56 UTC (permalink / raw)
  To: Hao Luo
  Cc: bpf, Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
	Martin KaFai Lau, Song Liu, Yonghong Song, KP Singh,
	Stanislav Fomichev, Jiri Olsa, John Fastabend, kernel-team

Hi Hao,

On Thu, Jan 12, 2023 at 02:18:05PM -0800, Hao Luo wrote:
> Feature request:
> 
> To support checking the type of a specific field directly.
> 
> Background:
> 
> Currently, As far as I know, CORE is able to check a field’s
> existence, offset, size and signedness, but not the field’s type
> directly.

Are you aware of the TYPE_MATCHES support [0] that was added a while back?
Specifically, for types to "match" they have to be of the same "kind" (struct
vs. struct, union vs. union, etc.). That check is done recursively for fields
from what I recall (please see linked change description or source code for more
details).

> There are changes that convert a field from a scalar type to a struct
> type, without changing the field’s name, offset or size. In that case,
> it is currently difficult to use CORE to check such changes. For a
> concrete example,
> 
> Commit 94a9717b3c (“locking/rwsem: Make rwsem->owner an atomic_long_t”)
> 
> Changed the type of rw_semaphore::owner from tast_struct * to
> atomic_long_t. In that change, the field name, offset and size remain
> the same. But the BPF program code used to extract the value is
> different. For the kernel where the field is a pointer, we can write:
> 
> sem->owner
> 
> While in the kernel where the field is an atomic, we need to write:
> 
> sem->owner.counter.
> 
> It would be great to be able to check a field’s type directly.
> Probably something like:
> 
> #include “vmlinux.h”
> 
> struct rw_semaphore__old {
>         struct task_struct *owner;
> };
> 
> struct rw_semaphore__new {
>         atomic_long_t owner;
> };
> 
> u64 owner;
> if (bpf_core_field_type_is(sem->owner, struct task_struct *)) {
>         struct rw_semaphore__old *old = (struct rw_semaphore__old *)sem;
>         owner = (u64)sem->owner;
> } else if (bpf_core_field_type_is(sem->owner, atomic_long_t)) {
>         struct rw_semaphore__new *new = (struct rw_semaphore__new *)sem;
>         owner = new->owner.counter;
> }

I haven't tried it out, but from the top of my head, TYPE_MATCHES should be able
to help with this case. If not, it may be useful for us to understand why it is
insufficient. Could you share feedback?

Thanks,
Daniel

[0]: https://lore.kernel.org/bpf/20220620231713.2143355-5-deso@posteo.net/

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: CORE feature request: support checking field type directly
  2023-01-17 21:56 ` Daniel Müller
@ 2023-01-17 22:21   ` Daniel Müller
  2023-01-18  0:55     ` Hao Luo
  0 siblings, 1 reply; 13+ messages in thread
From: Daniel Müller @ 2023-01-17 22:21 UTC (permalink / raw)
  To: Hao Luo
  Cc: bpf, Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
	Martin KaFai Lau, Song Liu, Yonghong Song, KP Singh,
	Stanislav Fomichev, Jiri Olsa, John Fastabend, kernel-team

I apologize for the response. Somehow Andrii's reply and the entire thread was
lost on me. Anyway, glad it's working for you.

Thanks,
Daniel

On Tue, Jan 17, 2023 at 09:56:58PM +0000, Daniel Müller wrote:
> Hi Hao,
> 
> On Thu, Jan 12, 2023 at 02:18:05PM -0800, Hao Luo wrote:
> > Feature request:
> > 
> > To support checking the type of a specific field directly.
> > 
> > Background:
> > 
> > Currently, As far as I know, CORE is able to check a field’s
> > existence, offset, size and signedness, but not the field’s type
> > directly.
> 
> Are you aware of the TYPE_MATCHES support [0] that was added a while back?
> Specifically, for types to "match" they have to be of the same "kind" (struct
> vs. struct, union vs. union, etc.). That check is done recursively for fields
> from what I recall (please see linked change description or source code for more
> details).
> 
> > There are changes that convert a field from a scalar type to a struct
> > type, without changing the field’s name, offset or size. In that case,
> > it is currently difficult to use CORE to check such changes. For a
> > concrete example,
> > 
> > Commit 94a9717b3c (“locking/rwsem: Make rwsem->owner an atomic_long_t”)
> > 
> > Changed the type of rw_semaphore::owner from tast_struct * to
> > atomic_long_t. In that change, the field name, offset and size remain
> > the same. But the BPF program code used to extract the value is
> > different. For the kernel where the field is a pointer, we can write:
> > 
> > sem->owner
> > 
> > While in the kernel where the field is an atomic, we need to write:
> > 
> > sem->owner.counter.
> > 
> > It would be great to be able to check a field’s type directly.
> > Probably something like:
> > 
> > #include “vmlinux.h”
> > 
> > struct rw_semaphore__old {
> >         struct task_struct *owner;
> > };
> > 
> > struct rw_semaphore__new {
> >         atomic_long_t owner;
> > };
> > 
> > u64 owner;
> > if (bpf_core_field_type_is(sem->owner, struct task_struct *)) {
> >         struct rw_semaphore__old *old = (struct rw_semaphore__old *)sem;
> >         owner = (u64)sem->owner;
> > } else if (bpf_core_field_type_is(sem->owner, atomic_long_t)) {
> >         struct rw_semaphore__new *new = (struct rw_semaphore__new *)sem;
> >         owner = new->owner.counter;
> > }
> 
> I haven't tried it out, but from the top of my head, TYPE_MATCHES should be able
> to help with this case. If not, it may be useful for us to understand why it is
> insufficient. Could you share feedback?
> 
> Thanks,
> Daniel
> 
> [0]: https://lore.kernel.org/bpf/20220620231713.2143355-5-deso@posteo.net/

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: CORE feature request: support checking field type directly
  2023-01-17 22:21   ` Daniel Müller
@ 2023-01-18  0:55     ` Hao Luo
  2023-01-31  6:06       ` Namhyung Kim
  0 siblings, 1 reply; 13+ messages in thread
From: Hao Luo @ 2023-01-18  0:55 UTC (permalink / raw)
  To: Daniel Müller
  Cc: bpf, Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
	Martin KaFai Lau, Song Liu, Yonghong Song, KP Singh,
	Stanislav Fomichev, Jiri Olsa, John Fastabend, kernel-team

Hi Daniel,

On Tue, Jan 17, 2023 at 2:22 PM Daniel Müller <deso@posteo.net> wrote:
>
> I apologize for the response. Somehow Andrii's reply and the entire thread was
> lost on me. Anyway, glad it's working for you.
>

Andrii helped me get it work. TYPE_MATCHES is a solution to my
problem. Now I have a better understanding on how
bpf_core_type_matches works.

For the record, the following works on my old kernel and new kernels:

struct rw_semaphore___old {
        struct task_struct *owner;
};

struct rw_semaphore___new {
        atomic_long_t owner;
};

u64 owner;
if (bpf_core_type_matches(struct rw_semaphore___old)) { /* owner is
task_struct pointer */
        struct rw_semaphore___old *old = (struct rw_semaphore___old *)sem;
        owner = (u64)sem->owner;
} else if (bpf_core_type_matches(struct rw_semaphore___new)) { /*
owner field is atomic_long_t */
        struct rw_semaphore___new *new = (struct rw_semaphore___new *)sem;
        owner = (u64)new->owner.counter;
}

Thanks for your response!
Hao

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: CORE feature request: support checking field type directly
  2023-01-18  0:55     ` Hao Luo
@ 2023-01-31  6:06       ` Namhyung Kim
  2023-01-31 16:46         ` Daniel Müller
  0 siblings, 1 reply; 13+ messages in thread
From: Namhyung Kim @ 2023-01-31  6:06 UTC (permalink / raw)
  To: Hao Luo
  Cc: Daniel Müller, bpf, Alexei Starovoitov, Daniel Borkmann,
	Andrii Nakryiko, Martin KaFai Lau, Song Liu, Yonghong Song,
	KP Singh, Stanislav Fomichev, Jiri Olsa, John Fastabend,
	kernel-team

Hi Hao,

On Tue, Jan 17, 2023 at 04:55:44PM -0800, Hao Luo wrote:
> Hi Daniel,
> 
> On Tue, Jan 17, 2023 at 2:22 PM Daniel Müller <deso@posteo.net> wrote:
> >
> > I apologize for the response. Somehow Andrii's reply and the entire thread was
> > lost on me. Anyway, glad it's working for you.
> >
> 
> Andrii helped me get it work. TYPE_MATCHES is a solution to my
> problem. Now I have a better understanding on how
> bpf_core_type_matches works.
> 
> For the record, the following works on my old kernel and new kernels:
> 
> struct rw_semaphore___old {
>         struct task_struct *owner;
> };
> 
> struct rw_semaphore___new {
>         atomic_long_t owner;
> };
> 
> u64 owner;
> if (bpf_core_type_matches(struct rw_semaphore___old)) { /* owner is
> task_struct pointer */
>         struct rw_semaphore___old *old = (struct rw_semaphore___old *)sem;
>         owner = (u64)sem->owner;
> } else if (bpf_core_type_matches(struct rw_semaphore___new)) { /*
> owner field is atomic_long_t */
>         struct rw_semaphore___new *new = (struct rw_semaphore___new *)sem;
>         owner = (u64)new->owner.counter;
> }
 
Thanks for taking care of this.  It looks good!

But I'm seeing a compiler error with this change like below.
("Incorrect flag for llvm.bpf.preserve.type.info intrinsic")
Maybe we need to check if the compiler supports it?

Thanks,
Namhyung


    CLANG   /home/namhyung/project/linux/tools/perf/util/bpf_skel/.tmp/lock_contention.bpf.o
  fatal error: error in backend: Incorrect flag for llvm.bpf.preserve.type.info intrinsic
  PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script.
  Stack dump:
  0.	Program arguments: clang -g -O2 -target bpf -Wall -Werror -I/home/namhyung/project/linux/tools/perf/util/bpf_skel/.tmp/.. -I/home/namhyung/project/linux/tools/perf/libbpf/include -c util/bpf_skel/lock_contention.bpf.c -o /home/namhyung/project/linux/tools/perf/util/bpf_skel/.tmp/lock_contention.bpf.o
  1.	<eof> parser at end of file
  2.	Optimizer
   #0 0x00007f1a070a5291 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/lib/x86_64-linux-gnu/libLLVM-14.so.1+0xea5291)
   #1 0x00007f1a070a2fbe llvm::sys::RunSignalHandlers() (/lib/x86_64-linux-gnu/libLLVM-14.so.1+0xea2fbe)
   #2 0x00007f1a070a464b llvm::sys::CleanupOnSignal(unsigned long) (/lib/x86_64-linux-gnu/libLLVM-14.so.1+0xea464b)
   #3 0x00007f1a06fcb62a (/lib/x86_64-linux-gnu/libLLVM-14.so.1+0xdcb62a)
   #4 0x00007f1a06fcb5cb (/lib/x86_64-linux-gnu/libLLVM-14.so.1+0xdcb5cb)
   #5 0x00007f1a0709f627 llvm::sys::Process::Exit(int, bool) (/lib/x86_64-linux-gnu/libLLVM-14.so.1+0xe9f627)
   #6 0x00000000004142c2 (/usr/lib/llvm-14/bin/clang+0x4142c2)
   #7 0x00007f1a06fda393 llvm::report_fatal_error(llvm::Twine const&, bool) (/lib/x86_64-linux-gnu/libLLVM-14.so.1+0xdda393)
   #8 0x00007f1a06fda276 (/lib/x86_64-linux-gnu/libLLVM-14.so.1+0xdda276)
   #9 0x00007f1a091d4d54 (/lib/x86_64-linux-gnu/libLLVM-14.so.1+0x2fd4d54)
  #10 0x00007f1a091d0434 (/lib/x86_64-linux-gnu/libLLVM-14.so.1+0x2fd0434)
  #11 0x00007f1a091d01a5 (/lib/x86_64-linux-gnu/libLLVM-14.so.1+0x2fd01a5)
  #12 0x00007f1a091e431d (/lib/x86_64-linux-gnu/libLLVM-14.so.1+0x2fe431d)
  #13 0x00007f1a07214d8e llvm::PassManager<llvm::Function, llvm::AnalysisManager<llvm::Function> >::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) (/lib/x86_64-linux-gnu/libLLVM-14.so.1+0x1014d8e)
  #14 0x00007f1a08e0ec0d (/lib/x86_64-linux-gnu/libLLVM-14.so.1+0x2c0ec0d)
  #15 0x00007f1a07218cb1 llvm::ModuleToFunctionPassAdaptor::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) (/lib/x86_64-linux-gnu/libLLVM-14.so.1+0x1018cb1)
  #16 0x00007f1a08e0ea3d (/lib/x86_64-linux-gnu/libLLVM-14.so.1+0x2c0ea3d)
  #17 0x00007f1a072139ae llvm::PassManager<llvm::Module, llvm::AnalysisManager<llvm::Module> >::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) (/lib/x86_64-linux-gnu/libLLVM-14.so.1+0x10139ae)
  #18 0x00007f1a0e4938ee (/lib/x86_64-linux-gnu/libclang-cpp.so.14+0x18938ee)
  #19 0x00007f1a0e4890e6 clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::StringRef, llvm::Module*, clang::BackendAction, std::unique_ptr<llvm::raw_pwrite_stream, std::default_delete<llvm::raw_pwrite_stream> >) (/lib/x86_64-linux-gnu/libclang-cpp.so.14+0x18890e6)
  #20 0x00007f1a0e7adf95 (/lib/x86_64-linux-gnu/libclang-cpp.so.14+0x1badf95)
  #21 0x00007f1a0d634914 clang::ParseAST(clang::Sema&, bool, bool) (/lib/x86_64-linux-gnu/libclang-cpp.so.14+0xa34914)
  #22 0x00007f1a0e7aa261 clang::CodeGenAction::ExecuteAction() (/lib/x86_64-linux-gnu/libclang-cpp.so.14+0x1baa261)
  #23 0x00007f1a0f14b887 clang::FrontendAction::Execute() (/lib/x86_64-linux-gnu/libclang-cpp.so.14+0x254b887)
  #24 0x00007f1a0f0a11f6 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/lib/x86_64-linux-gnu/libclang-cpp.so.14+0x24a11f6)
  #25 0x00007f1a0f1c563b clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/lib/x86_64-linux-gnu/libclang-cpp.so.14+0x25c563b)
  #26 0x0000000000413e93 cc1_main(llvm::ArrayRef<char const*>, char const*, void*) (/usr/lib/llvm-14/bin/clang+0x413e93)
  #27 0x00000000004120cc (/usr/lib/llvm-14/bin/clang+0x4120cc)
  #28 0x00007f1a0ed1d052 (/lib/x86_64-linux-gnu/libclang-cpp.so.14+0x211d052)
  #29 0x00007f1a06fcb5ad llvm::CrashRecoveryContext::RunSafely(llvm::function_ref<void ()>) (/lib/x86_64-linux-gnu/libLLVM-14.so.1+0xdcb5ad)
  #30 0x00007f1a0ed1cb50 clang::driver::CC1Command::Execute(llvm::ArrayRef<llvm::Optional<llvm::StringRef> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*, bool*) const (/lib/x86_64-linux-gnu/libclang-cpp.so.14+0x211cb50)
  #31 0x00007f1a0ece70f3 clang::driver::Compilation::ExecuteCommand(clang::driver::Command const&, clang::driver::Command const*&) const (/lib/x86_64-linux-gnu/libclang-cpp.so.14+0x20e70f3)
  #32 0x00007f1a0ece737a clang::driver::Compilation::ExecuteJobs(clang::driver::JobList const&, llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const*> >&) const (/lib/x86_64-linux-gnu/libclang-cpp.so.14+0x20e737a)
  #33 0x00007f1a0ed01677 clang::driver::Driver::ExecuteCompilation(clang::driver::Compilation&, llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const*> >&) (/lib/x86_64-linux-gnu/libclang-cpp.so.14+0x2101677)
  #34 0x0000000000411b36 main (/usr/lib/llvm-14/bin/clang+0x411b36)
  #35 0x00007f1a0604618a __libc_start_call_main ./csu/../sysdeps/nptl/libc_start_call_main.h:74:3
  #36 0x00007f1a06046245 call_init ./csu/../csu/libc-start.c:128:20
  #37 0x00007f1a06046245 __libc_start_main ./csu/../csu/libc-start.c:368:5
  #38 0x000000000040efb1 _start (/usr/lib/llvm-14/bin/clang+0x40efb1)
  clang: error: clang frontend command failed with exit code 70 (use -v to see invocation)
  Debian clang version 14.0.6
  Target: bpf
  Thread model: posix
  InstalledDir: /usr/bin


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: CORE feature request: support checking field type directly
  2023-01-31  6:06       ` Namhyung Kim
@ 2023-01-31 16:46         ` Daniel Müller
  2023-01-31 19:58           ` Namhyung Kim
  0 siblings, 1 reply; 13+ messages in thread
From: Daniel Müller @ 2023-01-31 16:46 UTC (permalink / raw)
  To: Namhyung Kim
  Cc: Hao Luo, bpf, Alexei Starovoitov, Daniel Borkmann,
	Andrii Nakryiko, Martin KaFai Lau, Song Liu, Yonghong Song,
	KP Singh, Stanislav Fomichev, Jiri Olsa, John Fastabend,
	kernel-team

Hi Namhyung,

On Mon, Jan 30, 2023 at 10:06:34PM -0800, Namhyung Kim wrote:
> Thanks for taking care of this.  It looks good!
> 
> But I'm seeing a compiler error with this change like below.
> ("Incorrect flag for llvm.bpf.preserve.type.info intrinsic")
> Maybe we need to check if the compiler supports it?
> 
> Thanks,
> Namhyung
> 
> 
>     CLANG   /home/namhyung/project/linux/tools/perf/util/bpf_skel/.tmp/lock_contention.bpf.o
>   fatal error: error in backend: Incorrect flag for llvm.bpf.preserve.type.info intrinsic
>   PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script.
>   Stack dump:
>   0.	Program arguments: clang -g -O2 -target bpf -Wall -Werror -I/home/namhyung/project/linux/tools/perf/util/bpf_skel/.tmp/.. -I/home/namhyung/project/linux/tools/perf/libbpf/include -c util/bpf_skel/lock_contention.bpf.c -o /home/namhyung/project/linux/tools/perf/util/bpf_skel/.tmp/lock_contention.bpf.o
>   1.	<eof> parser at end of file
>   2.	Optimizer
>    #0 0x00007f1a070a5291 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/lib/x86_64-linux-gnu/libLLVM-14.so.1+0xea5291)
>    #1 0x00007f1a070a2fbe llvm::sys::RunSignalHandlers() (/lib/x86_64-linux-gnu/libLLVM-14.so.1+0xea2fbe)
>    #2 0x00007f1a070a464b llvm::sys::CleanupOnSignal(unsigned long) (/lib/x86_64-linux-gnu/libLLVM-14.so.1+0xea464b)
>    #3 0x00007f1a06fcb62a (/lib/x86_64-linux-gnu/libLLVM-14.so.1+0xdcb62a)
>    #4 0x00007f1a06fcb5cb (/lib/x86_64-linux-gnu/libLLVM-14.so.1+0xdcb5cb)
>    #5 0x00007f1a0709f627 llvm::sys::Process::Exit(int, bool) (/lib/x86_64-linux-gnu/libLLVM-14.so.1+0xe9f627)
>    #6 0x00000000004142c2 (/usr/lib/llvm-14/bin/clang+0x4142c2)
>    #7 0x00007f1a06fda393 llvm::report_fatal_error(llvm::Twine const&, bool) (/lib/x86_64-linux-gnu/libLLVM-14.so.1+0xdda393)
>    #8 0x00007f1a06fda276 (/lib/x86_64-linux-gnu/libLLVM-14.so.1+0xdda276)
>    #9 0x00007f1a091d4d54 (/lib/x86_64-linux-gnu/libLLVM-14.so.1+0x2fd4d54)
>   #10 0x00007f1a091d0434 (/lib/x86_64-linux-gnu/libLLVM-14.so.1+0x2fd0434)
>   #11 0x00007f1a091d01a5 (/lib/x86_64-linux-gnu/libLLVM-14.so.1+0x2fd01a5)
>   #12 0x00007f1a091e431d (/lib/x86_64-linux-gnu/libLLVM-14.so.1+0x2fe431d)
>   #13 0x00007f1a07214d8e llvm::PassManager<llvm::Function, llvm::AnalysisManager<llvm::Function> >::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) (/lib/x86_64-linux-gnu/libLLVM-14.so.1+0x1014d8e)
>   #14 0x00007f1a08e0ec0d (/lib/x86_64-linux-gnu/libLLVM-14.so.1+0x2c0ec0d)
>   #15 0x00007f1a07218cb1 llvm::ModuleToFunctionPassAdaptor::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) (/lib/x86_64-linux-gnu/libLLVM-14.so.1+0x1018cb1)
>   #16 0x00007f1a08e0ea3d (/lib/x86_64-linux-gnu/libLLVM-14.so.1+0x2c0ea3d)
>   #17 0x00007f1a072139ae llvm::PassManager<llvm::Module, llvm::AnalysisManager<llvm::Module> >::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) (/lib/x86_64-linux-gnu/libLLVM-14.so.1+0x10139ae)
>   #18 0x00007f1a0e4938ee (/lib/x86_64-linux-gnu/libclang-cpp.so.14+0x18938ee)
>   #19 0x00007f1a0e4890e6 clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::StringRef, llvm::Module*, clang::BackendAction, std::unique_ptr<llvm::raw_pwrite_stream, std::default_delete<llvm::raw_pwrite_stream> >) (/lib/x86_64-linux-gnu/libclang-cpp.so.14+0x18890e6)
>   #20 0x00007f1a0e7adf95 (/lib/x86_64-linux-gnu/libclang-cpp.so.14+0x1badf95)
>   #21 0x00007f1a0d634914 clang::ParseAST(clang::Sema&, bool, bool) (/lib/x86_64-linux-gnu/libclang-cpp.so.14+0xa34914)
>   #22 0x00007f1a0e7aa261 clang::CodeGenAction::ExecuteAction() (/lib/x86_64-linux-gnu/libclang-cpp.so.14+0x1baa261)
>   #23 0x00007f1a0f14b887 clang::FrontendAction::Execute() (/lib/x86_64-linux-gnu/libclang-cpp.so.14+0x254b887)
>   #24 0x00007f1a0f0a11f6 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/lib/x86_64-linux-gnu/libclang-cpp.so.14+0x24a11f6)
>   #25 0x00007f1a0f1c563b clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/lib/x86_64-linux-gnu/libclang-cpp.so.14+0x25c563b)
>   #26 0x0000000000413e93 cc1_main(llvm::ArrayRef<char const*>, char const*, void*) (/usr/lib/llvm-14/bin/clang+0x413e93)
>   #27 0x00000000004120cc (/usr/lib/llvm-14/bin/clang+0x4120cc)
>   #28 0x00007f1a0ed1d052 (/lib/x86_64-linux-gnu/libclang-cpp.so.14+0x211d052)
>   #29 0x00007f1a06fcb5ad llvm::CrashRecoveryContext::RunSafely(llvm::function_ref<void ()>) (/lib/x86_64-linux-gnu/libLLVM-14.so.1+0xdcb5ad)
>   #30 0x00007f1a0ed1cb50 clang::driver::CC1Command::Execute(llvm::ArrayRef<llvm::Optional<llvm::StringRef> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*, bool*) const (/lib/x86_64-linux-gnu/libclang-cpp.so.14+0x211cb50)
>   #31 0x00007f1a0ece70f3 clang::driver::Compilation::ExecuteCommand(clang::driver::Command const&, clang::driver::Command const*&) const (/lib/x86_64-linux-gnu/libclang-cpp.so.14+0x20e70f3)
>   #32 0x00007f1a0ece737a clang::driver::Compilation::ExecuteJobs(clang::driver::JobList const&, llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const*> >&) const (/lib/x86_64-linux-gnu/libclang-cpp.so.14+0x20e737a)
>   #33 0x00007f1a0ed01677 clang::driver::Driver::ExecuteCompilation(clang::driver::Compilation&, llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const*> >&) (/lib/x86_64-linux-gnu/libclang-cpp.so.14+0x2101677)
>   #34 0x0000000000411b36 main (/usr/lib/llvm-14/bin/clang+0x411b36)
>   #35 0x00007f1a0604618a __libc_start_call_main ./csu/../sysdeps/nptl/libc_start_call_main.h:74:3
>   #36 0x00007f1a06046245 call_init ./csu/../csu/libc-start.c:128:20
>   #37 0x00007f1a06046245 __libc_start_main ./csu/../csu/libc-start.c:368:5
>   #38 0x000000000040efb1 _start (/usr/lib/llvm-14/bin/clang+0x40efb1)
>   clang: error: clang frontend command failed with exit code 70 (use -v to see invocation)
>   Debian clang version 14.0.6
>   Target: bpf
>   Thread model: posix
>   InstalledDir: /usr/bin

Not a compiler expert, but I am pretty sure that LLVM 14 does not have
TYPE_MATCH support (unless I missed a backport somewhere). That's likely
what "Incorrect flag for llvm.bpf.preserve.type.info intrinsic" refers
to. If I recall correctly the feature landed somewhere in the
development cycle of LLVM 15. I recommend you try with version 15 or
later.

Thanks,
Daniel

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: CORE feature request: support checking field type directly
  2023-01-31 16:46         ` Daniel Müller
@ 2023-01-31 19:58           ` Namhyung Kim
  0 siblings, 0 replies; 13+ messages in thread
From: Namhyung Kim @ 2023-01-31 19:58 UTC (permalink / raw)
  To: Daniel Müller
  Cc: Hao Luo, bpf, Alexei Starovoitov, Daniel Borkmann,
	Andrii Nakryiko, Martin KaFai Lau, Song Liu, Yonghong Song,
	KP Singh, Stanislav Fomichev, Jiri Olsa, John Fastabend,
	kernel-team

Hello Daniel,

On Tue, Jan 31, 2023 at 8:46 AM Daniel Müller <deso@posteo.net> wrote:
>
> Hi Namhyung,
>
> On Mon, Jan 30, 2023 at 10:06:34PM -0800, Namhyung Kim wrote:
> > Thanks for taking care of this.  It looks good!
> >
> > But I'm seeing a compiler error with this change like below.
> > ("Incorrect flag for llvm.bpf.preserve.type.info intrinsic")
> > Maybe we need to check if the compiler supports it?
> >
> > Thanks,
> > Namhyung
> >
> >
> >     CLANG   /home/namhyung/project/linux/tools/perf/util/bpf_skel/.tmp/lock_contention.bpf.o
> >   fatal error: error in backend: Incorrect flag for llvm.bpf.preserve.type.info intrinsic
> >   PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script.
> >   Stack dump:
> >   0.  Program arguments: clang -g -O2 -target bpf -Wall -Werror -I/home/namhyung/project/linux/tools/perf/util/bpf_skel/.tmp/.. -I/home/namhyung/project/linux/tools/perf/libbpf/include -c util/bpf_skel/lock_contention.bpf.c -o /home/namhyung/project/linux/tools/perf/util/bpf_skel/.tmp/lock_contention.bpf.o
> >   1.  <eof> parser at end of file
> >   2.  Optimizer
> >    #0 0x00007f1a070a5291 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/lib/x86_64-linux-gnu/libLLVM-14.so.1+0xea5291)
> >    #1 0x00007f1a070a2fbe llvm::sys::RunSignalHandlers() (/lib/x86_64-linux-gnu/libLLVM-14.so.1+0xea2fbe)
> >    #2 0x00007f1a070a464b llvm::sys::CleanupOnSignal(unsigned long) (/lib/x86_64-linux-gnu/libLLVM-14.so.1+0xea464b)
> >    #3 0x00007f1a06fcb62a (/lib/x86_64-linux-gnu/libLLVM-14.so.1+0xdcb62a)
> >    #4 0x00007f1a06fcb5cb (/lib/x86_64-linux-gnu/libLLVM-14.so.1+0xdcb5cb)
> >    #5 0x00007f1a0709f627 llvm::sys::Process::Exit(int, bool) (/lib/x86_64-linux-gnu/libLLVM-14.so.1+0xe9f627)
> >    #6 0x00000000004142c2 (/usr/lib/llvm-14/bin/clang+0x4142c2)
> >    #7 0x00007f1a06fda393 llvm::report_fatal_error(llvm::Twine const&, bool) (/lib/x86_64-linux-gnu/libLLVM-14.so.1+0xdda393)
> >    #8 0x00007f1a06fda276 (/lib/x86_64-linux-gnu/libLLVM-14.so.1+0xdda276)
> >    #9 0x00007f1a091d4d54 (/lib/x86_64-linux-gnu/libLLVM-14.so.1+0x2fd4d54)
> >   #10 0x00007f1a091d0434 (/lib/x86_64-linux-gnu/libLLVM-14.so.1+0x2fd0434)
> >   #11 0x00007f1a091d01a5 (/lib/x86_64-linux-gnu/libLLVM-14.so.1+0x2fd01a5)
> >   #12 0x00007f1a091e431d (/lib/x86_64-linux-gnu/libLLVM-14.so.1+0x2fe431d)
> >   #13 0x00007f1a07214d8e llvm::PassManager<llvm::Function, llvm::AnalysisManager<llvm::Function> >::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) (/lib/x86_64-linux-gnu/libLLVM-14.so.1+0x1014d8e)
> >   #14 0x00007f1a08e0ec0d (/lib/x86_64-linux-gnu/libLLVM-14.so.1+0x2c0ec0d)
> >   #15 0x00007f1a07218cb1 llvm::ModuleToFunctionPassAdaptor::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) (/lib/x86_64-linux-gnu/libLLVM-14.so.1+0x1018cb1)
> >   #16 0x00007f1a08e0ea3d (/lib/x86_64-linux-gnu/libLLVM-14.so.1+0x2c0ea3d)
> >   #17 0x00007f1a072139ae llvm::PassManager<llvm::Module, llvm::AnalysisManager<llvm::Module> >::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) (/lib/x86_64-linux-gnu/libLLVM-14.so.1+0x10139ae)
> >   #18 0x00007f1a0e4938ee (/lib/x86_64-linux-gnu/libclang-cpp.so.14+0x18938ee)
> >   #19 0x00007f1a0e4890e6 clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::StringRef, llvm::Module*, clang::BackendAction, std::unique_ptr<llvm::raw_pwrite_stream, std::default_delete<llvm::raw_pwrite_stream> >) (/lib/x86_64-linux-gnu/libclang-cpp.so.14+0x18890e6)
> >   #20 0x00007f1a0e7adf95 (/lib/x86_64-linux-gnu/libclang-cpp.so.14+0x1badf95)
> >   #21 0x00007f1a0d634914 clang::ParseAST(clang::Sema&, bool, bool) (/lib/x86_64-linux-gnu/libclang-cpp.so.14+0xa34914)
> >   #22 0x00007f1a0e7aa261 clang::CodeGenAction::ExecuteAction() (/lib/x86_64-linux-gnu/libclang-cpp.so.14+0x1baa261)
> >   #23 0x00007f1a0f14b887 clang::FrontendAction::Execute() (/lib/x86_64-linux-gnu/libclang-cpp.so.14+0x254b887)
> >   #24 0x00007f1a0f0a11f6 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/lib/x86_64-linux-gnu/libclang-cpp.so.14+0x24a11f6)
> >   #25 0x00007f1a0f1c563b clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/lib/x86_64-linux-gnu/libclang-cpp.so.14+0x25c563b)
> >   #26 0x0000000000413e93 cc1_main(llvm::ArrayRef<char const*>, char const*, void*) (/usr/lib/llvm-14/bin/clang+0x413e93)
> >   #27 0x00000000004120cc (/usr/lib/llvm-14/bin/clang+0x4120cc)
> >   #28 0x00007f1a0ed1d052 (/lib/x86_64-linux-gnu/libclang-cpp.so.14+0x211d052)
> >   #29 0x00007f1a06fcb5ad llvm::CrashRecoveryContext::RunSafely(llvm::function_ref<void ()>) (/lib/x86_64-linux-gnu/libLLVM-14.so.1+0xdcb5ad)
> >   #30 0x00007f1a0ed1cb50 clang::driver::CC1Command::Execute(llvm::ArrayRef<llvm::Optional<llvm::StringRef> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*, bool*) const (/lib/x86_64-linux-gnu/libclang-cpp.so.14+0x211cb50)
> >   #31 0x00007f1a0ece70f3 clang::driver::Compilation::ExecuteCommand(clang::driver::Command const&, clang::driver::Command const*&) const (/lib/x86_64-linux-gnu/libclang-cpp.so.14+0x20e70f3)
> >   #32 0x00007f1a0ece737a clang::driver::Compilation::ExecuteJobs(clang::driver::JobList const&, llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const*> >&) const (/lib/x86_64-linux-gnu/libclang-cpp.so.14+0x20e737a)
> >   #33 0x00007f1a0ed01677 clang::driver::Driver::ExecuteCompilation(clang::driver::Compilation&, llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const*> >&) (/lib/x86_64-linux-gnu/libclang-cpp.so.14+0x2101677)
> >   #34 0x0000000000411b36 main (/usr/lib/llvm-14/bin/clang+0x411b36)
> >   #35 0x00007f1a0604618a __libc_start_call_main ./csu/../sysdeps/nptl/libc_start_call_main.h:74:3
> >   #36 0x00007f1a06046245 call_init ./csu/../csu/libc-start.c:128:20
> >   #37 0x00007f1a06046245 __libc_start_main ./csu/../csu/libc-start.c:368:5
> >   #38 0x000000000040efb1 _start (/usr/lib/llvm-14/bin/clang+0x40efb1)
> >   clang: error: clang frontend command failed with exit code 70 (use -v to see invocation)
> >   Debian clang version 14.0.6
> >   Target: bpf
> >   Thread model: posix
> >   InstalledDir: /usr/bin
>
> Not a compiler expert, but I am pretty sure that LLVM 14 does not have
> TYPE_MATCH support (unless I missed a backport somewhere). That's likely
> what "Incorrect flag for llvm.bpf.preserve.type.info intrinsic" refers
> to. If I recall correctly the feature landed somewhere in the
> development cycle of LLVM 15. I recommend you try with version 15 or
> later.

Thanks for the info.  That means I need to add a version check
not to break the user programs with some old compilers.

Thanks,
Namhyung

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2023-01-31 19:58 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-01-12 22:18 CORE feature request: support checking field type directly Hao Luo
2023-01-13 23:41 ` Andrii Nakryiko
2023-01-14  1:06   ` Hao Luo
2023-01-14  1:14     ` Andrii Nakryiko
2023-01-14  2:19       ` Hao Luo
2023-01-14  2:44         ` Andrii Nakryiko
2023-01-17 18:45           ` Hao Luo
2023-01-17 21:56 ` Daniel Müller
2023-01-17 22:21   ` Daniel Müller
2023-01-18  0:55     ` Hao Luo
2023-01-31  6:06       ` Namhyung Kim
2023-01-31 16:46         ` Daniel Müller
2023-01-31 19:58           ` Namhyung Kim

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.