Linux Kernel Selftest development
 help / color / mirror / Atom feed
From: Tony Ambardar <tony.ambardar@gmail.com>
To: Eduard Zingerman <eddyz87@gmail.com>
Cc: bpf@vger.kernel.org, linux-kselftest@vger.kernel.org,
	Andrii Nakryiko <andrii@kernel.org>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Martin KaFai Lau <martin.lau@linux.dev>,
	Song Liu <song@kernel.org>,
	Yonghong Song <yonghong.song@linux.dev>,
	John Fastabend <john.fastabend@gmail.com>,
	KP Singh <kpsingh@kernel.org>,
	Stanislav Fomichev <sdf@fomichev.me>, Hao Luo <haoluo@google.com>,
	Jiri Olsa <jolsa@kernel.org>, Mykola Lysenko <mykolal@fb.com>,
	Shuah Khan <shuah@kernel.org>,
	Ilya Leoshkevich <iii@linux.ibm.com>,
	Quentin Monnet <qmo@kernel.org>
Subject: Re: [PATCH bpf-next v4 4/8] libbpf: Support BTF.ext loading and output in either endianness
Date: Mon, 16 Sep 2024 01:20:20 -0700	[thread overview]
Message-ID: <ZufqRH47gxTSVqMR@kodidev-ubuntu> (raw)
In-Reply-To: <d407fa343213b4bc5990de24e0f322add91a874e.camel@gmail.com>

On Fri, Aug 30, 2024 at 05:15:06PM -0700, Eduard Zingerman wrote:
> On Fri, 2024-08-30 at 00:29 -0700, Tony Ambardar wrote:
> 
> [...]
> 
> > @@ -3050,11 +3127,42 @@ static int btf_ext_parse_hdr(__u8 *data, __u32 data_size)
> >  		return -ENOTSUP;
> >  	}
> >  
> > -	if (data_size == hdr->hdr_len) {
> > +	if (data_size < hdr_len) {
> > +		pr_debug("BTF.ext header not found\n");
> > +		return -EINVAL;
> > +	} else if (data_size == hdr_len) {
> >  		pr_debug("BTF.ext has no data\n");
> >  		return -EINVAL;
> >  	}
> >  
> > +	/* Verify mandatory hdr info details present */
> > +	if (hdr_len < offsetofend(struct btf_ext_header, line_info_len)) {
> > +		pr_warn("BTF.ext header missing func_info, line_info\n");
> > +		return -EINVAL;
> > +	}
> > +
> > +	/* Keep hdr native byte-order in memory for introspection */
> > +	if (btf_ext->swapped_endian)
> > +		btf_ext_bswap_hdr(btf_ext, hdr_len);
> > +
> > +	/* Basic info section consistency checks*/
> > +	info_size = btf_ext->data_size - hdr_len;
> > +	if (info_size & 0x03) {
> > +		pr_warn("BTF.ext info size not 4-byte multiple\n");
> > +		return -EINVAL;
> > +	}
> > +	info_size -= hdr->func_info_len + hdr->line_info_len;
> > +	if (hdr_len >= offsetofend(struct btf_ext_header, core_relo_len))
> > +		info_size -= hdr->core_relo_len;
> 
> nit: Since we are checking this, maybe also check that sections do not overlap?
>      Also, why disallowing gaps between sections?
> 
> > +	if (info_size) {
> > +		pr_warn("BTF.ext info size mismatch with header data\n");
> > +		return -EINVAL;
> > +	}
> > +
> > +	/* Keep infos native byte-order in memory for introspection */
> > +	if (btf_ext->swapped_endian)
> > +		btf_ext_bswap_info(btf_ext, !btf_ext->swapped_endian);
> > +
> >  	return 0;
> >  }
> 
> [...]
> 
> > @@ -3119,15 +3223,71 @@ struct btf_ext *btf_ext__new(const __u8 *data, __u32 size)
> >  	return btf_ext;
> >  }
> >  
> > +static void *btf_ext_raw_data(const struct btf_ext *btf_ext_ro, __u32 *size,
> > +			      bool swap_endian)
> > +{
> > +	struct btf_ext *btf_ext = (struct btf_ext *)btf_ext_ro;
> > +	const __u32 data_sz = btf_ext->data_size;
> > +	void *data;
> > +
> > +	data = swap_endian ? btf_ext->data_swapped : btf_ext->data;
> > +	if (data) {
> > +		*size = data_sz;
> > +		return data;
> > +	}
> > +
> > +	data = calloc(1, data_sz);
> > +	if (!data)
> > +		return NULL;
> > +	memcpy(data, btf_ext->data, data_sz);
> > +
> > +	if (swap_endian) {
> > +		btf_ext_bswap_info(btf_ext, true);
> > +		btf_ext_bswap_hdr(btf_ext, btf_ext->hdr->hdr_len);
> > +		btf_ext->data_swapped = data;
> > +	}
> 
> Nit: I don't like how this function is organized:
>      - if btf_ext->data can't be NULL swap_endian == true at this point;
>      - if btf_ext->data can be NULL and swap_endian == false
>        pointer to `data` would be lost.
> 
>      I assume that btf_ext->data can't be null, basing on the
>      btf_ext__new(), but function body is a bit confusing.

Hi Eduard,

Sorry, I saw this earlier but dropped my reply by mistake I think. You're
right that btf_ext->data can't be null, and the awkwardness above is a
holdover from trying to use the btf_raw_data() code, where it _can_ be
null. I've rewritten it to be clearer for the next v6 series, which also
reuses existing info sec validation and drops the extra code you referred
to further above.

Thanks,
Tony

> 
> > +
> > +	*size = data_sz;
> > +	return data;
> > +}
> > +
> 
> [...]
> 

  reply	other threads:[~2024-09-16  8:20 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-30  7:29 [PATCH bpf-next v4 0/8] libbpf, selftests/bpf: Support cross-endian usage Tony Ambardar
2024-08-30  7:29 ` [PATCH bpf-next v4 1/8] libbpf: Improve log message formatting Tony Ambardar
2024-08-30  7:29 ` [PATCH bpf-next v4 2/8] libbpf: Fix header comment typos for BTF.ext Tony Ambardar
2024-08-30  7:29 ` [PATCH bpf-next v4 3/8] libbpf: Fix output .symtab byte-order during linking Tony Ambardar
2024-08-30 22:15   ` Eduard Zingerman
2024-09-01  5:59     ` Tony Ambardar
2024-08-30  7:29 ` [PATCH bpf-next v4 4/8] libbpf: Support BTF.ext loading and output in either endianness Tony Ambardar
2024-08-30 21:14   ` Andrii Nakryiko
2024-09-02  8:19     ` Tony Ambardar
2024-09-04 19:55       ` Andrii Nakryiko
2024-08-31  0:15   ` Eduard Zingerman
2024-09-16  8:20     ` Tony Ambardar [this message]
2024-08-30  7:29 ` [PATCH bpf-next v4 5/8] libbpf: Support opening bpf objects of " Tony Ambardar
2024-08-30 21:25   ` Andrii Nakryiko
2024-08-31  1:26     ` Eduard Zingerman
2024-09-01  6:05       ` Tony Ambardar
2024-09-01  6:03     ` Tony Ambardar
2024-08-31  1:16   ` Eduard Zingerman
2024-09-01  6:04     ` Tony Ambardar
2024-08-30  7:29 ` [PATCH bpf-next v4 6/8] libbpf: Support linking " Tony Ambardar
2024-08-30 21:25   ` Andrii Nakryiko
2024-09-01  6:02     ` Tony Ambardar
2024-08-30  7:29 ` [PATCH bpf-next v4 7/8] libbpf: Support creating light skeleton " Tony Ambardar
2024-08-30 21:30   ` Andrii Nakryiko
2024-08-31  1:24     ` Alexei Starovoitov
2024-09-01  6:02       ` Tony Ambardar
2024-09-01  6:00     ` Tony Ambardar
2024-08-30  7:29 ` [PATCH bpf-next v4 8/8] selftests/bpf: Support cross-endian building Tony Ambardar

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=ZufqRH47gxTSVqMR@kodidev-ubuntu \
    --to=tony.ambardar@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=eddyz87@gmail.com \
    --cc=haoluo@google.com \
    --cc=iii@linux.ibm.com \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=kpsingh@kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=martin.lau@linux.dev \
    --cc=mykolal@fb.com \
    --cc=qmo@kernel.org \
    --cc=sdf@fomichev.me \
    --cc=shuah@kernel.org \
    --cc=song@kernel.org \
    --cc=yonghong.song@linux.dev \
    /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