| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <aP-LE7ssid10iKw-@x1>
Date: Mon, 27 Oct 2025 12:09:07 -0300
From: Arnaldo Carvalho de Melo <acme@...nel.org>
To: Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc: Jiayuan Chen <jiayuan.chen@...ux.dev>,
Alan Maguire <alan.maguire@...cle.com>,
Anton Protopopov <a.s.protopopov@...il.com>,
Yonghong Song <yonghong.song@...ux.dev>, bpf <bpf@...r.kernel.org>,
Andrii Nakryiko <andrii@...nel.org>,
Eduard Zingerman <eddyz87@...il.com>,
Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
Martin KaFai Lau <martin.lau@...ux.dev>, Song Liu <song@...nel.org>,
John Fastabend <john.fastabend@...il.com>,
KP Singh <kpsingh@...nel.org>, Stanislav Fomichev <sdf@...ichev.me>,
Hao Luo <haoluo@...gle.com>, Jiri Olsa <jolsa@...nel.org>,
Shuah Khan <shuah@...nel.org>,
Nathan Chancellor <nathan@...nel.org>,
Nick Desaulniers <nick.desaulniers+lkml@...il.com>,
Bill Wendling <morbo@...gle.com>,
Justin Stitt <justinstitt@...gle.com>,
Puranjay Mohan <puranjay@...nel.org>,
"open list:KERNEL SELFTEST FRAMEWORK" <linux-kselftest@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
clang-built-linux <llvm@...ts.linux.dev>
Subject: Re: pahole next->master. Was: [PATCH bpf-next v1] selftests/bpf:
Guard addr_space_cast code with __BPF_FEATURE_ADDR_SPACE_CAST
On Mon, Oct 27, 2025 at 11:58:43AM -0300, Arnaldo Carvalho de Melo wrote:
> On Thu, Oct 23, 2025 at 08:42:34AM -0700, Alexei Starovoitov wrote:
> > On Thu, Oct 23, 2025 at 12:50 AM Jiayuan Chen <jiayuan.chen@...ux.dev> wrote:
> > > thanks, but version 1.30 didn't work in my tests - even pahole's master branch fails, only the next branch works...
> > >
>
> > > It seems that the 'old' pahole parses some kfuncs incorrectly, for example bpf_dynptr_slice().
> l
> > Alan,
>
> > the introduction of the 'next' branch screwed up the workflow for many people.
> > Let's remove it and merge everything into master.
> > People expect master branch to be the one where active development
> > is happening and the source of truth for the latest features.
>
> My bad, I've been away for too long, next is supposed to be with things
> for a short while, testing for a few days, for CI consumption, then move
> to master, rinse repeat.
>
> I think we should go back to that model.
The difference is small but can explain as has changes to the btf
loader, and the reporter, as I now checked the whole thread, says that
'next' works for him, so I'll move what is in 'next' to 'master' now.
Just for reference since I had done it, my investigation is below.
- Arnaldo
⬢ [acme@...lbx pahole]$ git remote update korg
Fetching korg
⬢ [acme@...lbx pahole]$
⬢ [acme@...lbx pahole]$ git remote -v | grep korg
korg https://git.kernel.org/pub/scm/devel/pahole/pahole.git (fetch)
korg https://git.kernel.org/pub/scm/devel/pahole/pahole.git (push)
⬢ [acme@...lbx pahole]$ git diff --stat korg/master korg/next
warning: refname 'korg/next' is ambiguous.
.github/scripts/build-pahole.sh | 23 +++++++++++++++++++++++
.github/scripts/compare-functions.sh | 30 ++++++++++++++++++++++++++++++
.github/workflows/test.yml | 4 ++--
.github/workflows/vmtest.yml | 4 ++++
CMakeLists.txt | 5 -----
README | 4 ++++
btf_loader.c | 23 ++++++++++++++++++++---
dwarves_fprintf.c | 2 +-
8 files changed, 84 insertions(+), 11 deletions(-)
⬢ [acme@...lbx pahole]$
Related to btf bitfields:
diff --git a/btf_loader.c b/btf_loader.c
index f4f9f65289b5acac..64ea68022ab04e60 100644
--- a/btf_loader.c
+++ b/btf_loader.c
@@ -645,9 +645,15 @@ static int class__fixup_btf_bitfields(const struct conf_load *conf, struct tag *
pos->byte_size = tag__size(type, cu);
pos->bit_size = pos->byte_size * 8;
- /* if BTF data is incorrect and has size == 0, skip field,
- * instead of crashing */
+ /* If the BTF data is incorrect and has size == 0, skip field
+ * instead of crashing. However the field can be a zero or
+ * variable-length array and we still need to infer alignment.
+ */
if (pos->byte_size == 0) {
+ pos->alignment = class__infer_alignment(conf,
+ pos->byte_offset,
+ tag__natural_alignment(type, cu),
+ smallest_offset);
continue;
}
@@ -672,7 +678,18 @@ static int class__fixup_btf_bitfields(const struct conf_load *conf, struct tag *
pos->byte_offset,
tag__natural_alignment(type, cu),
smallest_offset);
- smallest_offset = pos->byte_offset + pos->byte_size;
+
+ /* Compute the smallest offset between this field and the next
+ * one.
+ *
+ * In case of bitfields we need to take into account the
+ * actual size being used instead of the underlying type one as
+ * it could be larger, otherwise we could miss a hole.
+ */
+ smallest_offset = pos->byte_offset;
+ smallest_offset += pos->bitfield_size ?
+ (pos->bitfield_offset + pos->bitfield_size + 7) / 8 :
+ pos->byte_size;
}
tag_type->alignment = class__infer_alignment(conf,
Powered by blists - more mailing lists