Package: release.debian.org Severity: normal User: release.debian....@packages.debian.org Usertags: unblock X-Debbugs-Cc: dwar...@packages.debian.org, Aurelien Jarno <aure...@debian.org>, k...@debian.org, vagr...@debian.org, Domenico Andreoli <ca...@debian.org>, car...@debian.org Control: affects -1 + src:dwarves
Dear release team, Please unblock package dwarves [ Reason ] Back in #1033301, Aurelien reported that the arm64 kernel size did increase significantly due to issues with BTF deduplication. First suspected to be a Linux kernel upstream issue, Aurelien discussed this on with upstream and it was found that the issue is caused by a src:dwarves regression (applied in 1.24-4). Details in https://bugs.debian.org/1033301#31 The (not yet uploaded) dwarves upload with attache debdiff cherry-picks the upstream commit. (Please provide enough (but not too much) information to help the release team to judge the request efficiently. E.g. by filling in the sections below.) [ Impact ] Increased arm64 kernel size. [ Tests ] Apart from the report from Aurelien[1], package passes its autopkgtest. [1] https://lore.kernel.org/linux-arm-kernel/zezhajup21ln5...@aurel32.net/ [ Risks ] The upstream commit zero-initializes memory which previous was not initialized after allocation, and might have contained garbage values which were used. The fix is isolated as a oneliner. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing [ Other info ] Ideally this enters the archive before a next upload for src:linux is built (and which would be aimed for bookworm). unblock dwarves/1.24-4.1 Regards, Salvatore
diff -Nru dwarves-1.24/debian/changelog dwarves-1.24/debian/changelog --- dwarves-1.24/debian/changelog 2022-12-10 10:11:28.000000000 +0100 +++ dwarves-1.24/debian/changelog 2023-05-02 20:37:16.000000000 +0200 @@ -1,3 +1,13 @@ +dwarves (1.24-4.1) unstable; urgency=medium + + * Non-maintainer upload. + * dwarves: Zero-initialize struct cu in cu__new() to prevent incorrect BTF + types. + Fixes BTF deduplication issues causing arm64 kernel size increase. + Thanks to Aurelien Jarno (Closes: #1033301) + + -- Salvatore Bonaccorso <car...@debian.org> Tue, 02 May 2023 20:37:16 +0200 + dwarves (1.24-4) unstable; urgency=medium * Backport upstream patches to support newer toolchains. diff -Nru dwarves-1.24/debian/patches/03-dwarves-Zero-initialize-struct-cu-in-cu__new-to-prev.patch dwarves-1.24/debian/patches/03-dwarves-Zero-initialize-struct-cu-in-cu__new-to-prev.patch --- dwarves-1.24/debian/patches/03-dwarves-Zero-initialize-struct-cu-in-cu__new-to-prev.patch 1970-01-01 01:00:00.000000000 +0100 +++ dwarves-1.24/debian/patches/03-dwarves-Zero-initialize-struct-cu-in-cu__new-to-prev.patch 2023-05-02 20:37:16.000000000 +0200 @@ -0,0 +1,94 @@ +From: Alan Maguire <alan.magu...@oracle.com> +Date: Fri, 21 Oct 2022 16:02:03 +0100 +Subject: dwarves: Zero-initialize struct cu in cu__new() to prevent incorrect + BTF types +Origin: https://git.kernel.org/pub/scm/devel/pahole/pahole.git/commit?id=b72f5188856df0abf45e1a707856bb4e4e86153c +Bug-Debian: https://bugs.debian.org/1033301 + +BTF deduplication was throwing some strange results, where core kernel +data types were failing to deduplicate due to the return values +of function type members being void (0) instead of the actual type +(unsigned int). An example of this can be seen below, where +"struct dst_ops" was failing to deduplicate between kernel and +module: + +struct dst_ops { + short unsigned int family; + unsigned int gc_thresh; + int (*gc)(struct dst_ops *); + struct dst_entry * (*check)(struct dst_entry *, __u32); + unsigned int (*default_advmss)(const struct dst_entry *); + unsigned int (*mtu)(const struct dst_entry *); +... + +struct dst_ops___2 { + short unsigned int family; + unsigned int gc_thresh; + int (*gc)(struct dst_ops___2 *); + struct dst_entry___2 * (*check)(struct dst_entry___2 *, __u32); + void (*default_advmss)(const struct dst_entry___2 *); + void (*mtu)(const struct dst_entry___2 *); +... + +This was seen with + +bcc648a10cbc ("btf_encoder: Encode DW_TAG_unspecified_type returning routines as void") + +...which rewrites the return value as 0 (void) when it is marked +as matching DW_TAG_unspecified_type: + +static int32_t btf_encoder__tag_type(struct btf_encoder *encoder, uint32_t type_id_off, uint32_t tag_type) +{ + if (tag_type == 0) + return 0; + + if (encoder->cu->unspecified_type.tag && tag_type == encoder->cu->unspecified_type.type) { + // No provision for encoding this, turn it into void. + return 0; + } + + return type_id_off + tag_type; +} + +However the odd thing was that on further examination, the unspecified type +was not being set, so why was this logic being tripped? Futher debugging +showed that the encoder->cu->unspecified_type.tag value was garbage, and +the type id happened to collide with "unsigned int"; as a result we +were replacing unsigned ints with void return values, and since this +was being done to function type members in structs, it triggered a +type mismatch which failed deduplication between kernel and module. + +The fix is simply to calloc() the cu in cu__new() instead. + +Committer notes: + +We have zalloc(size) as an alias to calloc(1, size), use it instead. + +Fixes: bcc648a10cbcd0b9 ("btf_encoder: Encode DW_TAG_unspecified_type returning routines as void") +Signed-off-by: Alan Maguire <alan.magu...@oracle.com> +Acked-by: Andrii Nakryiko <and...@kernel.org> +Acked-by: Jiri Olsa <jo...@kernel.org> +Cc: b...@vger.kernel.org +Cc: dwar...@vger.kernel.org +Link: https://lore.kernel.org/r/1666364523-9648-1-git-send-email-alan.magu...@oracle.com +Signed-off-by: Arnaldo Carvalho de Melo <a...@redhat.com> +--- + dwarves.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/dwarves.c b/dwarves.c +index fbebc1dda501..95a3bac0e36f 100644 +--- a/dwarves.c ++++ b/dwarves.c +@@ -626,7 +626,7 @@ struct cu *cu__new(const char *name, uint8_t addr_size, + const unsigned char *build_id, int build_id_len, + const char *filename, bool use_obstack) + { +- struct cu *cu = malloc(sizeof(*cu) + build_id_len); ++ struct cu *cu = zalloc(sizeof(*cu) + build_id_len); + + if (cu != NULL) { + uint32_t void_id; +-- +2.40.1 + diff -Nru dwarves-1.24/debian/patches/series dwarves-1.24/debian/patches/series --- dwarves-1.24/debian/patches/series 2022-12-10 10:11:28.000000000 +0100 +++ dwarves-1.24/debian/patches/series 2023-05-02 20:37:16.000000000 +0200 @@ -1,3 +1,4 @@ 00-store-the-CU-being-processed-to-avoid-changing-many-functions.patch 01-record-if-a-CU-has-a-DW_TAG_unspecified_type.patch 02-encode-DW_TAG_unspecified_type-returning-routines-as-void.patch +03-dwarves-Zero-initialize-struct-cu-in-cu__new-to-prev.patch
