bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Laight <David.Laight@ACULAB.COM>
To: 'Yonghong Song' <yhs@fb.com>, Shung-Hsi Yu <shung-hsi.yu@suse.com>
Cc: "Alexei Starovoitov" <alexei.starovoitov@gmail.com>,
	"Connor O'Brien" <connoro@google.com>,
	"Michal Suchánek" <msuchanek@suse.de>, bpf <bpf@vger.kernel.org>,
	"Network Development" <netdev@vger.kernel.org>,
	"Andrii Nakryiko" <andrii@kernel.org>,
	"Daniel Borkmann" <daniel@iogearbox.net>,
	"Alexei Starovoitov" <ast@kernel.org>
Subject: RE: BTF compatibility issue across builds
Date: Wed, 16 Feb 2022 08:48:46 +0000	[thread overview]
Message-ID: <634a6042dc76479bb12d6084ffe36f62@AcuMS.aculab.com> (raw)
In-Reply-To: <0867c12a-9aa3-418d-9102-3103cb784e99@fb.com>

From: Yonghong Song
> Sent: 15 February 2022 17:47
...
> > Let me try take a jab at it. Say here's a hypothetical BTF for a kernel
> > module which only type information for `struct something *`:
> >
> >    [5] PTR '(anon)' type_id=4
> >
> > Which is built upon the follow base BTF:
> >
> >    [1] INT 'unsigned char' size=1 bits_offset=0 nr_bits=8 encoding=(none)
> >    [2] PTR '(anon)' type_id=3
> >    [3] STRUCT 'list_head' size=16 vlen=2
> >          'next' type_id=2 bits_offset=0
> >          'prev' type_id=2 bits_offset=64
> >    [4] STRUCT 'something' size=2 vlen=2
> >          'locked' type_id=1 bits_offset=0
> >          'pending' type_id=1 bits_offset=8
> >
> > Due to the situation mentioned in the beginning of the thread, the *runtime*
> > kernel have a different base BTF, in this case type IDs are offset by 1 due
> > to an additional typedef entry:
> >
> >    [1] TYPEDEF 'u8' type_id=1
> >    [2] INT 'unsigned char' size=1 bits_offset=0 nr_bits=8 encoding=(none)
> >    [3] PTR '(anon)' type_id=3
> >    [4] STRUCT 'list_head' size=16 vlen=2
> >          'next' type_id=2 bits_offset=0
> >          'prev' type_id=2 bits_offset=64
> >    [5] STRUCT 'something' size=2 vlen=2
> >          'locked' type_id=1 bits_offset=0
> >          'pending' type_id=1 bits_offset=8
> >
> > Then when loading the BTF on kernel module on the runtime, the kernel will
> > mistakenly interprets "PTR '(anon)' type_id=4" as `struct list_head *`
> > rather than `struct something *`.
> >
> > Does this should possible? (at least theoretically)
> 
> Thanks for explanation. Yes, from BTF type resolution point of view,
> yes it is possible.

This looks so much like the old 'shared library function number'
ordinals from pre-SYSV and early windows shared libraries.
There is a good reason why it isn't done that way any more.

Has someone re-invented the square wheel??

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

  parent reply	other threads:[~2022-02-16  8:48 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-27 15:10 BTF compatibility issue across builds Shung-Hsi Yu
2022-01-31 17:36 ` Yonghong Song
2022-02-10 10:01   ` Michal Suchánek
2022-02-10 18:17     ` Yonghong Song
2022-02-10 22:34       ` Alexei Starovoitov
2022-02-10 22:59         ` Yonghong Song
2022-02-12  5:40           ` Shung-Hsi Yu
2022-02-12  6:36             ` Yonghong Song
2022-02-15 19:38               ` Shung-Hsi Yu
2022-02-15 17:47                 ` Yonghong Song
2022-02-15 18:57                   ` Toke Høiland-Jørgensen
2022-02-20  0:28                     ` Andrii Nakryiko
2022-02-16  8:48                   ` David Laight [this message]
2022-03-02 17:46                 ` Michal Suchánek
2022-03-03  4:27                   ` Shung-Hsi Yu
2022-02-11  6:01     ` Andrii Nakryiko
2022-02-11 17:20       ` Toke Høiland-Jørgensen
2022-02-11 22:20         ` Andrii Nakryiko
2022-02-11 23:58           ` Toke Høiland-Jørgensen
2022-02-12  7:37             ` Shung-Hsi Yu
2022-02-13 15:40               ` Toke Høiland-Jørgensen
2022-02-14 20:19                 ` Michal Suchánek

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=634a6042dc76479bb12d6084ffe36f62@AcuMS.aculab.com \
    --to=david.laight@aculab.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=connoro@google.com \
    --cc=daniel@iogearbox.net \
    --cc=msuchanek@suse.de \
    --cc=netdev@vger.kernel.org \
    --cc=shung-hsi.yu@suse.com \
    --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 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).