bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Forney <mforney@mforney.org>
To: Daniel Borkmann <daniel@iogearbox.net>
Cc: "Toke Høiland-Jørgensen" <toke@redhat.com>,
	"Andrii Nakryiko" <andrii.nakryiko@gmail.com>,
	"Andrii Nakryiko" <andriin@fb.com>, bpf <bpf@vger.kernel.org>,
	Networking <netdev@vger.kernel.org>,
	"Alexei Starovoitov" <ast@fb.com>,
	"Kernel Team" <kernel-team@fb.com>, "Yonghong Song" <yhs@fb.com>
Subject: Re: [PATCH v3 bpf-next 1/3] bpf: switch BPF UAPI #define constants used from BPF program side to enums
Date: Mon, 1 Jun 2020 22:31:34 -0700	[thread overview]
Message-ID: <CAGw6cBuCwmbULDq2v76SWqVYL2o8i+pBg7JnDi=F+6Wcq3SDTA@mail.gmail.com> (raw)
In-Reply-To: <945cf1c4-78bb-8d3c-10e3-273d100ce41c@iogearbox.net>

Hi,

On 2020-03-04, Daniel Borkmann <daniel@iogearbox.net> wrote:
> I was about to push the series out, but agree that there may be a risk for
> #ifndefs
> in the BPF C code. If we want to be on safe side, #define FOO FOO would be
> needed.

I did indeed hit some breakage due to this change, but not for the
anticipated reason.

The C standard requires that enumeration constants be representable as
an int, and have type int. While it is a common extension to allow
constants that exceed the limits of int, and this is required
elsewhere in Linux UAPI headers, this is the first case I've
encountered where the constant is not representable as unsigned int
either:

	enum {
		BPF_F_CTXLEN_MASK		= (0xfffffULL << 32),
	};

To see why this can be problematic, consider the following program:

	#include <stdio.h>
	
	enum {
		A = 1,
		B = 0x80000000,
		C = 1ULL << 32,
	
		A1 = sizeof(A),
		B1 = sizeof(B),
	};
	
	enum {
		A2 = sizeof(A),
		B2 = sizeof(B),
	};
	
	int main(void) {
		printf("sizeof(A) = %d, %d\n", (int)A1, (int)A2);
		printf("sizeof(B) = %d, %d\n", (int)B1, (int)B2);
	}

You might be surprised by the output:

	sizeof(A) = 4, 4
	sizeof(B) = 4, 8

This is because the type of B is different inside and outside the
enum. In my C compiler, I have implemented the extension only for
constants that fit in unsigned int to avoid these confusing semantics.

Since BPF_F_CTXLEN_MASK is the only offending constant, is it possible
to restore its definition as a macro?

Also, I'm not sure if it was considered, but using enums also changes
the signedness of these constants. Many of the previous macro
expressions had type unsigned long long, and now they have type int
(the type of the expression specifying the constant value does not
matter). I could see this causing problems if these constants are used
in expressions involving shifts or implicit conversions.

Thanks for your time,

-Michael

  parent reply	other threads:[~2020-06-02  5:31 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-03  0:32 [PATCH v3 bpf-next 0/3] Convert BPF UAPI constants into enum values Andrii Nakryiko
2020-03-03  0:32 ` [PATCH v3 bpf-next 1/3] bpf: switch BPF UAPI #define constants used from BPF program side to enums Andrii Nakryiko
2020-03-03 23:01   ` Daniel Borkmann
2020-03-03 23:24     ` Andrii Nakryiko
2020-03-04  9:37       ` Toke Høiland-Jørgensen
2020-03-04 15:38         ` Daniel Borkmann
2020-03-04 15:50           ` Alexei Starovoitov
2020-03-04 16:03             ` Daniel Borkmann
2020-03-04 15:57           ` Daniel Borkmann
2020-03-04 16:02             ` Andrii Nakryiko
2020-03-04 16:07             ` Alexei Starovoitov
2020-03-05 10:50             ` Toke Høiland-Jørgensen
2020-06-02  5:31           ` Michael Forney [this message]
2020-06-02 19:17             ` Alexei Starovoitov
2020-06-02 21:40               ` Michael Forney
2020-06-02 23:07                 ` Alexei Starovoitov
2020-06-02 23:21                   ` Michael Forney
2020-06-02 23:36                     ` Alexei Starovoitov
2020-06-03 21:22                       ` Michael Forney
2020-03-03  0:32 ` [PATCH v3 bpf-next 2/3] libbpf: assume unsigned values for BTF_KIND_ENUM Andrii Nakryiko
2020-03-03  0:32 ` [PATCH v3 bpf-next 3/3] tools/runqslower: drop copy/pasted BPF_F_CURRENT_CPU definiton Andrii Nakryiko
2020-03-04 15:21 ` [PATCH v3 bpf-next 0/3] Convert BPF UAPI constants into enum values Daniel Borkmann
2020-03-04 15:34   ` Andrii Nakryiko

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='CAGw6cBuCwmbULDq2v76SWqVYL2o8i+pBg7JnDi=F+6Wcq3SDTA@mail.gmail.com' \
    --to=mforney@mforney.org \
    --cc=andrii.nakryiko@gmail.com \
    --cc=andriin@fb.com \
    --cc=ast@fb.com \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=kernel-team@fb.com \
    --cc=netdev@vger.kernel.org \
    --cc=toke@redhat.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).