On 29 April 2023 11:56:19 CEST, Salvatore Bonaccorso <car...@debian.org> wrote:
>Hi Aurelien,
>
>On Sat, Apr 29, 2023 at 09:50:57AM +0200, Aurelien Jarno wrote:
>> control: reassign -1 pahole/1.24-4
>> control: retitle -1 pahole: BTF deduplication issues causing arm64 kernel
>> size increase
>> control: tag -1 + fixed-upstream
>> control: tag -1 + patch
>> control: affects -1 u-boot-rpi src:linux
>>
>> Hi,
>>
>> On 2023-03-21 23:11, Aurelien Jarno wrote:
>> > Source: linux
>> > Version: 6.1.15-1
>> > Severity: important
>> > Tags: upstream
>> > X-Debbugs-Cc: vagr...@debian.org
>> > Control: affects -1 + u-boot-rpi
>> >
>> > Hi,
>> >
>> > Following the upgrade of the kernel from 6.1.12-1 to 6.1.15-1 on a
>> > Raspberry Pi 3 Model B Plus, u-boot (from the u-boot-rpi package) failed
>> > to boot with:
>> >
>> > | 40175552 bytes read in 1695 ms (23 MiB/s)
>> > | 43794863 bytes read in 1817 ms (23 MiB/s)
>> > | Moving Image from 0x80000 to 0x200000, end=2990000
>> > | ERROR: RD image overlaps OS image (OS=0x200000..0x2990000)
>> >
>> > I tracked the issue to a significant increase of the kernel size between
>> > version 6.1.12-1 and 6.15-1:
>> >
>> > | 31492 /boot/vmlinuz-6.1.0-5-arm64
>> > | 39236 /boot/vmlinuz-6.1.0-6-arm64
>> >
>> > This is more than the 36MB that is allowed by u-boot with the default
>> > load addresses. A workaround is to shift the load addresses at the
>> > u-boot level as in the attached patch.
>> >
>> > I have tracked issue on the upstream kernel side to the following commit
>> > on the stable tree:
>> >
>> > | commit 3e3e4d234d46e48480a7c7c35399fa811182e8ef
>> > | Author: Masahiro Yamada <masahi...@kernel.org>
>> > | Date: Thu Oct 13 08:35:00 2022 +0900
>> > |
>> > | arm64: remove special treatment for the link order of head.o
>> > |
>> > | commit 994b7ac1697b4581b7726d2ac64321e3c840229b upstream.
>> > |
>> > | In the previous discussion (see the Link tag), Ard pointed out that
>> > | arm/arm64/kernel/head.o does not need any special treatment - the
>> > only
>> > | piece that must appear right at the start of the binary image is the
>> > | image header which is emitted into .head.text.
>> > |
>> > | The linker script does the right thing to do. The build system does
>> > | not need to manipulate the link order of head.o.
>> > |
>> > | Link:
>> > https://lore.kernel.org/lkml/CAMj1kXH77Ja8bSsq2Qj8Ck9iSZKw=1F8Uy-uAWGVDm4-CG=e...@mail.gmail.com/
>> > | Suggested-by: Ard Biesheuvel <a...@kernel.org>
>> > | Signed-off-by: Masahiro Yamada <masahi...@kernel.org>
>> > | Reviewed-by: Nicolas Schier <nico...@fjasle.eu>
>> > | Link:
>> > https://lore.kernel.org/r/20221012233500.156764-1-masahi...@kernel.org
>> > | Signed-off-by: Will Deacon <w...@kernel.org>
>> > | Signed-off-by: Tom Saeger <tom.sae...@oracle.com>
>> > | Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
>> >
>> > The problem is still reproducible on Linus' master.
>> >
>> > I am reporting the bug to the linux package as I believed there is no
>> > real reason for such an increase in the kernel size. In case I missed
>> > something and this is actually wanted, the bug can be reassigned to the
>> > u-boot package.
>>
>> This has been discussed upstream, and it appears that the issue is not
>> reproducible with pahole 1.25. Looking at the part that needs to be
>> backported to the Debian package, I have found that the issue is caused
>> by the following patch backported in version 1.24-4:
>>
>> 02-encode-DW_TAG_unspecified_type-returning-routines-as-void.patch
>>
>> This patch has an issue, and memory is not initialized after allocation,
>> so garbage values are used instead. A one-liner fix has been committed
>> upstream not so long after the initial patch:
>>
>> https://git.kernel.org/pub/scm/devel/pahole/pahole.git/commit/?id=b72f5188856df0abf45e1a707856bb4e4e86153c
>>
>> I am therefore reassigning the bug to pahole where the bug should be
>> fixed. Even if Bookworm is now fully frozen, I personally believe this
>> bug should still be fixed before the release. That said, this has to be
>> discussed with the release team, and as pahole is a key package you need
>> a pre-approval *before* the upload to sid.
>
>Thanks for tracking this down!
>
>Domenico, I would say, it would eben be good to have this in in the
>archive for bookworm before the next (last?) linux upload for bookworm
>ideally. This is not yet planned but, the last one should probably be
>latest in the week of 15th May.
>
>Regards,
>Salvatore
Hi,
Apologies for not having sent a VAC message but I'm unable to handle this in
a timely manner.
Please proceed with a NMU.
Thanks,
Dom
