Re: [PATCH v8] arm64: kexec_file: Stop using the Image text_offset

[Jinjie Ruan <2118537295@qq.com>]

Hi Catalin,

在 2026/11/7 01:07, Catalin Marinas 写道:
> On Thu, Nov 05, 2026 at 08:54:42PM +0800, Jinjie Ruan wrote:
>> image_load() adds text_offset to kernel_segment->mem and subtracts it
>> from kernel_segment->memsz.  For CMA backed segments this breaks the
>> load path: the payload is copied to page_address(cma), which is the CMA
>> base, while image->start is set to the adjusted address, so kexec jumps
>> into the middle of the kernel.  kimage_map_segment() has the same
>> mismatch when a segment has been moved.
>>
>> The adjusted memsz also breaks the release path: the CMA pages are
>> freed using segment->memsz >> PAGE_SHIFT, which is fewer than were
>> allocated, leaking the tail of the allocation.
>>
>> Since commit 751c263bb74f ("arm64: remove TEXT_OFFSET randomization")
> 
> This commit only removed the randomisation. The one you want mentioned
> here is cfa7ede20f13 ("arm64: set TEXT_OFFSET to 0x0 in preparation for
> removing it entirely"). Although this removing never happened (see more
> below).

You  are right!  we should correct the commit.

> 
>> TEXT_OFFSET is always zero.  This has been upstream since v5.8, so no
>> LTS kernel carries a non-zero text_offset.  Drop the adjustment and
>> reject images with a non-zero value instead of booting them from a
>> wrong address.  With the adjustment gone, segments stay at their CMA
>> base and the release size matches the allocation.
>>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: Will Deacon <will@kernel.org>
>> Cc: Mike Rapoport <rppt@kernel.org>
>> Link: https://lore.kernel.org/all/20260921090450.807575-2-ruanjinjie@huawei.com/
>> Link: https://lore.kernel.org/all/20260921090450.807575-3-ruanjinjie@huawei.com/
>> Fixes: 07d24902977e ("kexec: enable CMA based contiguous allocation")
>> Suggested-by: Mike Rapoport <rppt@kernel.org>
>> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
>> ---
>> v2:
>> - Split out from the patch set.
>> - Link to v7: https://lore.kernel.org/all/20261026075201.699550-1-ruanjinjie@huawei.com/
>> ---
>>   arch/arm64/kernel/kexec_image.c | 13 ++++++++-----
>>   1 file changed, 8 insertions(+), 5 deletions(-)
>>
>> diff --git a/arch/arm64/kernel/kexec_image.c b/arch/arm64/kernel/kexec_image.c
>> index 78b1f956d8d7..7d6baea3d28f 100644
>> --- a/arch/arm64/kernel/kexec_image.c
>> +++ b/arch/arm64/kernel/kexec_image.c
>> @@ -80,12 +80,17 @@ static void *image_load(struct kimage *image,
>>   	kbuf.bufsz = kernel_len;
>>   	kbuf.mem = KEXEC_BUF_MEM_UNKNOWN;
>>   	kbuf.memsz = le64_to_cpu(h->image_size);
>> +	/*
>> +	 * Pre-v5.8 images carry a non-zero text_offset, which is no longer
>> +	 * honored; reject them instead of loading them at a wrong address.
>> +	 */
>>   	text_offset = le64_to_cpu(h->text_offset);
>> +	if (text_offset) {
>> +		pr_err("Unsupported Image text_offset 0x%lx\n", text_offset);
>> +		return ERR_PTR(-ENOEXEC);
>> +	}
> 
> If it's only CMA getting it wrong, can we not just set
> image->no_cma = true here and continue as normal?
> 

Yes, it also works.

I tested this cma problem on QEMU arm64 with cma=64M and an Image header
whose text_offset is 0x80000.
- Without fix , it jump 512K past the CMA copy and never boot;
- With the fix, it loads from normal memory and the second kernel boots.

> While text_offset is 0 now, I don't think we concluded it should be
> deprecated. There was a recent push back on the attempt to document the
> always 0 behaviour:

Thank you! I will fix it with your suggestion.

Best regards,
Jinjie

> 
> https://lore.kernel.org/all/20260604140839.1930847-1-linux@rasmusvillemoes.dk/
>