From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Alan Maguire <alan.maguire@oracle.com>
Cc: "Thomas Weißschuh" <linux@weissschuh.net>,
"Alexei Starovoitov" <ast@kernel.org>,
"Daniel Borkmann" <daniel@iogearbox.net>,
"Andrii Nakryiko" <andrii@kernel.org>,
"Martin KaFai Lau" <martin.lau@linux.dev>,
"Eduard Zingerman" <eddyz87@gmail.com>,
"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@google.com>,
"Hao Luo" <haoluo@google.com>, "Jiri Olsa" <jolsa@kernel.org>,
"Masahiro Yamada" <masahiroy@kernel.org>,
"Nathan Chancellor" <nathan@kernel.org>,
"Nicolas Schier" <nicolas@fjasle.eu>,
bpf@vger.kernel.org, linux-kbuild@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] kbuild: disable pahole multithreading for reproducible builds
Date: Fri, 22 Mar 2024 14:27:26 -0300 [thread overview]
Message-ID: <Zf2_fgs0cqW82zEu@x1> (raw)
In-Reply-To: <49fa2bd1-bd6e-4404-a1c7-2170d37f0194@oracle.com>
On Fri, Mar 22, 2024 at 10:07:00AM +0000, Alan Maguire wrote:
> On 22/03/2024 08:31, Thomas Weißschuh wrote:
> > A BTF type_id is a numeric identifier allocated by pahole through
> > libbpfd. Ids are incremented for each allocation.
> > Running pahole multithreaded makes the sequence of allocations
> > non-deterministic which also makes the type_id itself non-deterministic.
> > As the type_id end up in the binary this breaks reproducibility.
> >
> > Therefore, if the kernel is built reproducibly as indicated by
> > KBUILD_BUILD_TIMESTAMP, disable threading in pahole.
> >
> > Fixes: b4f72786429c ("scripts/pahole-flags.sh: Parse DWARF and generate BTF with multithreading.")
> > Fixes: 72d091846de9 ("kbuild: avoid too many execution of scripts/pahole-flags.sh")
> > Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
>
> Yep, we've talked about sorting final BTF in various ways but until that
> is implemented, non-parallel execution of pahole is the best way to get
> reliabily-reproducing BTF ids. We should probably update the pahole
So, the problem is about parallel BTF encoding, not so much about
parallel DWARF loading, which speeds up the whole process and could
continue if we make sure that we feed the BTF encoder in the same order
as when not doing anything in parallel.
I.e. a serial BTF encoding done at the same time as a parallel DWARF
loading would produce a reproducible build faster than doing
_everything_ serially.
The important point would be to feed the btf encoder the DWARF CUs in
the same order as when doing it serially.
No need to order anything, just create a linked list/array of CUs and
then start loading them and leave the BTF encoder go on taking CUs from
that linked list/array in the order they are in vmlinux.
- Arnaldo
> manpage to warn about parallel non-deterministic id allocation in the
> meantime.
>
> Reviewed-by: Alan Maguire <alan.maguire@oracle.com>
>
> > ---
> > scripts/Makefile.btf | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/scripts/Makefile.btf b/scripts/Makefile.btf
> > index 82377e470aed..2356929e62e4 100644
> > --- a/scripts/Makefile.btf
> > +++ b/scripts/Makefile.btf
> > @@ -10,7 +10,10 @@ endif
> >
> > pahole-flags-$(call test-ge, $(pahole-ver), 121) += --btf_gen_floats
> >
> > +# threaded execution randomizes BTF type_id allocation, breaking reproducibility
> > +ifeq ($(KBUILD_BUILD_TIMESTAMP),)
> > pahole-flags-$(call test-ge, $(pahole-ver), 122) += -j
> > +endif
> >
> > pahole-flags-$(CONFIG_PAHOLE_HAS_LANG_EXCLUDE) += --lang_exclude=rust
> >
> >
> > ---
> > base-commit: 8e938e39866920ddc266898e6ae1fffc5c8f51aa
> > change-id: 20240322-pahole-reprodicible-02e904e45686
> >
> > Best regards,
>
prev parent reply other threads:[~2024-03-22 17:27 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-22 8:31 [PATCH] kbuild: disable pahole multithreading for reproducible builds Thomas Weißschuh
2024-03-22 10:07 ` Alan Maguire
2024-03-22 17:27 ` Arnaldo Carvalho de Melo [this message]
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=Zf2_fgs0cqW82zEu@x1 \
--to=acme@kernel.org \
--cc=alan.maguire@oracle.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=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@weissschuh.net \
--cc=martin.lau@linux.dev \
--cc=masahiroy@kernel.org \
--cc=nathan@kernel.org \
--cc=nicolas@fjasle.eu \
--cc=sdf@google.com \
--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