Re: [PATCH v1 1/3] xen/riscv: fix switch_stack_and_jump()

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 19/05/2026 11:50 am, Oleksii Kurochko wrote:
>
>
> On 5/19/26 11:28 AM, Jan Beulich wrote:
>> On 19.05.2026 10:39, Oleksii Kurochko wrote:
>>> The following compilation issue occurs when UBSAN related stuff is
>>> enabled:
>>> prelink.o: in function `smp_processor_id':
>>>   
>>> /build/xen/./arch/riscv/include/asm/current.h:46:(.init.text+0x274e2):
>>>    relocation truncated to fit: R_RISCV_JAL against `init_done'
>>> make[2]: *** [arch/riscv/Makefile:45: xen-syms] Error 1
>>
>> There's no init_done() as of yet.
>
> It was found based on downstream version of RISC-V port.
>
>>
>>> The switch_stack_and_jump macro uses "j " #fn which assembles to
>>> JAL x0, init_done is a RISC-V J-type instruction with only ±1MB range.
>>>
>>> Without UBSAN, .init.text is small enough that init_done (which
>>> lives in
>>> .text, not .init.text) is within 1MB of the JAL. With UBSAN enabled,
>>> all
>>> the instrumentation calls bloat .init.text well past 1MB, so init_done
>>> is now >1MB away from the JAL. The linker tries to truncate the 20-bit
>>> J-type offset and fails.
>>
>> .init.text is well below 64k right now. Are you telling us that it grows
>> by more than a factor of 16 when UBSAN is enabled? IOW while the change
>> may indeed be needed, I question this explanation. .text growth may
>> matter
>> as well, and e.g. .rodata (living between both sections) might also
>> grow.
>
> No, it won't grow so much.
>
> With UBSAN enabled:
>
> $ objdump -h xen/prelink.o
>
> xen/prelink.o:     file format elf64-little
>
> Sections:
> Idx Name          Size      VMA               LMA               File off
>   0 .text         0011c79e  0000000000000000  0000000000000000  00000040
>                   CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
>   1 .init.text    000285fe  0000000000000000  0000000000000000  0011c7de
>                   CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
>
> With UBSAN, .text itself is 0x11c79e ≈ 1.11 MiB — already exceeding
> the JAL range on its own. Even if .init.text directly followed .text
> (which it doesn't), a call from .init.text to a symbol near the start
> of .text would be ~1.11 MiB away. init_done likely sits somewhere
> specific within .text rather than at its very end, but add the .rodata
> + .data sections on top and the gap is comfortably past ±1 MiB.
>
> As a result, the target symbol init_done may end up outside the range
> supported by the R_RISCV_JAL relocation, which is limited to
> approximately ±1 MiB.
>
> Without UBSAN enabled:
>
> xen/prelink.o:     file format elf64-little
>
> Sections:
> Idx Name          Size      VMA               LMA               File off
>   0 .text         00044618  0000000000000000  0000000000000000  00000040
>                   CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
>   1 .init.text    00012c72  0000000000000000  0000000000000000  00044658
>                   CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
>
> Does it make sense now? I can use the text above for commit message
> instead of what is mentioned now for more accuracy.
>
> Would it be better to send this patch when this issue will occur in
> upstream?

You want to make the commit message less specific.

The problem here is that JAL only has a +- 1M range, and that this can
be exceeded in some configurations.

The fact it's init_done(), and indeed that it's also UBSAN, are rather
incidental.  It's useful to state once, (including "found in a
downstream branch"), but don't focus on init_done().

Also the subject should be "fix switch_stack_and_jump() for range beyond
1M" or similar.  "fix" on it's own could be one of many things.

~Andrew