Re: [PATCH v6 2/8] hugetlb: restructure pool allocations

[Mike Kravetz]

On 10/09/23 12:11, Konrad Dybcio wrote:
> On 9.10.2023 05:29, Mike Kravetz wrote:
> > On 10/06/23 15:35, Mike Kravetz wrote:
> >> On 10/06/23 23:39, Konrad Dybcio wrote:
> >>> On 6.10.2023 05:08, Mike Kravetz wrote:
> >>>> On 10/02/23 11:57, Konrad Dybcio wrote:
> >>>>> On 9/29/23 22:57, Mike Kravetz wrote:
> >>>>>> On 09/27/23 13:26, Konrad Dybcio wrote:
> >>>>>>> On 26.09.2023 01:48, Mike Kravetz wrote:
>
> I managed to get a boot log:
> 
> https://pastebin.com/GwurpCw9
> 
> This is using arch/arm64/boot/dts/qcom/sm8550-mtp.dts for reference
> 

Early on in boot log before the panic, I see this in the log:

[    0.000000] efi: UEFI not found.
[    0.000000] [Firmware Bug]: Kernel image misaligned at boot, please fix your bootloader!

Isn't that misalignment pretty serious?  Or, is is possible to run with that?

There are no hugetlb pages allocated at boot time:

[    0.000000] Kernel command line: PMOS_NO_OUTPUT_REDIRECT console=ttyMSM0 earlycon clk_ignore_unused pd_ignore_unused androidboot.bootdevice=1d84000.ufshc androidboot.fstab_suffix=default androidboot.boot_devices=soc/1d84000.ufshc androidboot.serialno=ab855d8d androidboot.baseband=msm 

So, the routine where we are panic'ing (gather_bootmem_prealloc) should be a
noop.  The first thing it does is:
list_for_each_entry(m, &huge_boot_pages, list) {
...
}

However, huge_boot_pages should be empty as initialized here:
__initdata LIST_HEAD(huge_boot_pages);

At the end of the routine, we call prep_and_add_bootmem_folios to
process the local list created withing that above loop:

LIST_HEAD(folio_list);

This should also be empty and a noop.

Is it possible that the misaligned kernel image could make these lists
appear as non-empty?
-- 
Mike Kravetz