From: sashiko-bot@kernel.org
To: "Alan Maguire" <alan.maguire@oracle.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH v2 bpf-next 1/8] bpf: Extend BTF UAPI vlen, kinds to use unused bits
Date: Thu, 16 Apr 2026 19:05:07 +0000 [thread overview]
Message-ID: <20260416190508.8F093C2BCAF@smtp.kernel.org> (raw)
In-Reply-To: <20260416143904.1220662-2-alan.maguire@oracle.com>
Sashiko AI review found 1 potential issue(s):
- [High] UAPI C preprocessor breakage: Converting `BTF_MAX_*` constants to self-referential macros breaks existing `#if` evaluations in userspace.
--
commit ba6ded5102d9dc62d6101147f738a8a12d499303
Author: Alan Maguire <alan.maguire@oracle.com>
bpf: Extend BTF UAPI vlen, kinds to use unused bits
This commit extends BTF maximum vlen from 16 to 24 bits and kinds from
5 to 7 bits to support upcoming BTF location information. It converts the
BTF_MAX_* macros to an enum so they are encoded in kernel BTF, leaving
self-referential macros for backward compatibility.
Link: https://lore.kernel.org/bpf/CAEf4BzZx=X6vGqcA8SPU6D+v6k+TR=ZewebXMuXtpmML058piw@mail.gmail.com/
> diff --git a/include/uapi/linux/btf.h b/include/uapi/linux/btf.h
> --- a/include/uapi/linux/btf.h
> +++ b/include/uapi/linux/btf.h
[ ... ]
> +enum btf_max {
> + /* Max possible kind */
> + BTF_MAX_KIND = 0x0000007f,
> + /* Max # of type identifier */
> + BTF_MAX_TYPE = 0x000fffff,
> + /* Max offset into the string section */
> + BTF_MAX_NAME_OFFSET = 0x00ffffff,
> + /* Max # of struct/union/enum members or func args */
> + BTF_MAX_VLEN = 0x00ffffff,
> +};
> +
> +/*
> + * Macros needed for backwards compatibility; enum above ensures values
> + * make it into BTF.
> + */
> +#define BTF_MAX_TYPE BTF_MAX_TYPE
> +#define BTF_MAX_NAME_OFFSET BTF_MAX_NAME_OFFSET
> +#define BTF_MAX_VLEN BTF_MAX_VLEN
Will these self-referential macros break existing C preprocessor logic in
userspace?
While #ifdef BTF_MAX_VLEN will still evaluate to true, the preprocessor
does not have visibility into enum values. When evaluating #if directives
like #if BTF_MAX_VLEN == 0xffff, the macro expands to the identifier
BTF_MAX_VLEN, which is treated as an undefined symbol and evaluates to 0.
This means the check silently evaluates to false, which might break
build-time feature detection for userspace programs depending on this header.
Could these macros be defined to their exact integer literals after the enum
block instead?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260416143904.1220662-1-alan.maguire@oracle.com?part=1
next prev parent reply other threads:[~2026-04-16 19:05 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-16 14:38 [PATCH v2 bpf-next 0/8] bpf: Extend BTF UAPI vlen, kinds to use unused bits Alan Maguire
2026-04-16 14:38 ` [PATCH v2 bpf-next 1/8] " Alan Maguire
2026-04-16 15:54 ` Alexei Starovoitov
2026-04-16 19:05 ` sashiko-bot [this message]
2026-04-16 14:38 ` [PATCH v2 bpf-next 2/8] libbpf: Adjust btf_vlen() to return a __u32 Alan Maguire
2026-04-16 15:27 ` bot+bpf-ci
2026-04-16 19:36 ` sashiko-bot
2026-04-16 14:38 ` [PATCH v2 bpf-next 3/8] libbpf: Add feature for kernel extended vlen/kind support Alan Maguire
2026-04-16 15:27 ` bot+bpf-ci
2026-04-16 15:56 ` Alexei Starovoitov
2026-04-16 16:08 ` Alan Maguire
2026-04-16 20:01 ` sashiko-bot
2026-04-16 14:39 ` [PATCH v2 bpf-next 4/8] bpftool: Support 24-bit vlen Alan Maguire
2026-04-16 15:15 ` bot+bpf-ci
2026-04-16 14:39 ` [PATCH v2 bpf-next 5/8] selftests/bpf: Test BTF sanitization rejection for invalid vlen Alan Maguire
2026-04-16 15:27 ` bot+bpf-ci
2026-04-16 20:20 ` sashiko-bot
2026-04-16 14:39 ` [PATCH v2 bpf-next 6/8] selftests/bpf: Fix up btf/invalid test for extended kind Alan Maguire
2026-04-16 14:39 ` [PATCH v2 bpf-next 7/8] selftests/bpf: Fix up __u16 vlen assumptions Alan Maguire
2026-04-16 20:32 ` sashiko-bot
2026-04-16 14:39 ` [PATCH v2 bpf-next 8/8] Documentation/bpf: Update btf doc with updated vlen, kind sizes Alan Maguire
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=20260416190508.8F093C2BCAF@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=alan.maguire@oracle.com \
--cc=bpf@vger.kernel.org \
--cc=sashiko@lists.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 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.