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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 19.05.2026 12:50, 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?

Having the change right away is fine, but the description needs to match
what's presently upstream (i.e. mention any non-upstream aspect as such).

Jan