All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrii Nakryiko <andrii.nakryiko@gmail.com>
To: Hao Luo <haoluo@google.com>
Cc: bpf <bpf@vger.kernel.org>, Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	Martin KaFai Lau <martin.lau@linux.dev>,
	Song Liu <song@kernel.org>, Yonghong Song <yhs@fb.com>,
	KP Singh <kpsingh@kernel.org>,
	Stanislav Fomichev <sdf@google.com>, Jiri Olsa <jolsa@kernel.org>,
	John Fastabend <john.fastabend@gmail.com>
Subject: Re: CORE feature request: support checking field type directly
Date: Fri, 13 Jan 2023 17:14:08 -0800	[thread overview]
Message-ID: <CAEf4BzaQPtFMkcJdH4m5S0X5t3UD1M0M_bJk9Z65Zspb5bbxgA@mail.gmail.com> (raw)
In-Reply-To: <CA+khW7gXaHwxZjS1sp0oAF-t0jk0+CnwxdhV9kqyBfqEVack-w@mail.gmail.com>

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

  reply	other threads:[~2023-01-14  1:14 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAEf4BzaQPtFMkcJdH4m5S0X5t3UD1M0M_bJk9Z65Zspb5bbxgA@mail.gmail.com \
    --to=andrii.nakryiko@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=haoluo@google.com \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=kpsingh@kernel.org \
    --cc=martin.lau@linux.dev \
    --cc=sdf@google.com \
    --cc=song@kernel.org \
    --cc=yhs@fb.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.