Re: Bug#1033301: linux: arm64 kernel size increased from 31 to 39 MB, causing u-boot-rpi to fail

[Salvatore Bonaccorso <carnil@debian.org>]

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: vagrant@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 <masahiroy@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=EuA@mail.gmail.com/
> > |     Suggested-by: Ard Biesheuvel <ardb@kernel.org>
> > |     Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
> > |     Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
> > |     Link: https://lore.kernel.org/r/20221012233500.156764-1-masahiroy@kernel.org
> > |     Signed-off-by: Will Deacon <will@kernel.org>
> > |     Signed-off-by: Tom Saeger <tom.saeger@oracle.com>
> > |     Signed-off-by: Greg Kroah-Hartman <gregkh@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