bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Yonghong Song <yonghong.song@linux.dev>
To: Bryce Kahle <bryce.kahle@datadoghq.com>,
	Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: Bryce Kahle <git@brycekahle.com>,
	Quentin Monnet <quentin@isovalent.com>,
	bpf@vger.kernel.org, ast@kernel.org, daniel@iogearbox.net
Subject: Re: [PATCH bpf-next v4] bpftool: add support for split BTF to gen min_core_btf
Date: Wed, 7 Feb 2024 14:38:14 -0800	[thread overview]
Message-ID: <c4624866-894f-4340-ac97-41bbb683c149@linux.dev> (raw)
In-Reply-To: <CALvGib8LtTY8qBN+tvZTzb_GKNOX4R9YEUxkOL0ghuQmjG8Yqg@mail.gmail.com>


On 2/7/24 10:51 AM, Bryce Kahle wrote:
> On Mon, Feb 5, 2024 at 10:21 AM Andrii Nakryiko
> <andrii.nakryiko@gmail.com> wrote:
>> 3) btf__dedup() will deduplicate everything, so that only unique type
>> definitions remain.
>>
A random thought about another way.
At module side, we keep
   - module btf
   - another section (e.g. .BTF.extra) to keep minimum kernel-side
     types which directly used by module btf

   for example, module btf has
     struct foo {
       struct task_struct *t;
     }
     module btf encoding will have id, say 20,
     for 'struct task_struct' which is at that time
     the id in linux kernel.
   Then the module .BTF.extra contains
     id 20: struct task_struct type encoding
     there is no need to encode more types beyond pointers.
     this can be simpler or more complex depending
     on what to do during module load.

When a module load:
   For each .BTF.extra entry, trying to match
   the corresponding types in the current kernel.
   The type in the current type should have same
   size as the one in .BTF.extra if otherwise
   layout in the module btf may change.

   If new kernel type can be used for module BTF,
   simply replace the old id with new id in module BTF.

   Otherwise, type mismatch may happen and the corresponding
   module btf type should be invalidated.

> Since minimization only keeps used struct and union members, couldn't
> you have two internal types from different modules which conflict and
> end up using the wrong offset?
>
> Example:
> in module M:
> struct S {
> ... // other unused members
> int x; // offset 12 (for example)
> }
>
> in module N:
> struct S {
> ... // other unused members
> int x; // offset 20 (something different from S.x in module M)
> }
>

  reply	other threads:[~2024-02-07 22:38 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-30 23:05 [PATCH bpf-next v4] bpftool: add support for split BTF to gen min_core_btf Bryce Kahle
2024-01-31 18:13 ` Alan Maguire
2024-02-02 22:16   ` Andrii Nakryiko
2024-02-06 10:59     ` Alan Maguire
2024-02-08  0:26       ` Andrii Nakryiko
2024-02-08 22:45         ` Alan Maguire
2024-02-09 19:50           ` Andrii Nakryiko
2024-02-01  0:54 ` Quentin Monnet
2024-02-01 21:05   ` Bryce Kahle
2024-02-02 22:10     ` Andrii Nakryiko
2024-02-03  0:58       ` Bryce Kahle
2024-02-05 18:21         ` Andrii Nakryiko
2024-02-07 18:51           ` Bryce Kahle
2024-02-07 22:38             ` Yonghong Song [this message]
2024-02-08  0:30               ` Andrii Nakryiko
2024-02-08  1:56                 ` Yonghong Song
2024-02-08 23:01                   ` Alan Maguire
2024-02-09 19:58                     ` Andrii Nakryiko
2024-02-26 21:48           ` Bryce Kahle
2024-02-29  0:59             ` Andrii Nakryiko
2024-02-29 15:24               ` Quentin Monnet

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=c4624866-894f-4340-ac97-41bbb683c149@linux.dev \
    --to=yonghong.song@linux.dev \
    --cc=andrii.nakryiko@gmail.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=bryce.kahle@datadoghq.com \
    --cc=daniel@iogearbox.net \
    --cc=git@brycekahle.com \
    --cc=quentin@isovalent.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).