Re: [PATCH v3 10/23] xen/riscv: introduce init interrupt controller operations

[Jan Beulich <jbeulich@xxxxxxxx>]

On 24.06.2026 13:34, Oleksii Kurochko wrote:
> On 6/22/26 4:30 PM, Jan Beulich wrote:
>> On 17.06.2026 13:17, Oleksii Kurochko wrote:
>> Strictly speaking ...
>>
>>> --- a/xen/arch/riscv/aplic.c
>>> +++ b/xen/arch/riscv/aplic.c
>>> @@ -306,12 +306,16 @@ static const hw_irq_controller aplic_xen_irq_type = {
>>>   
>>>   static const struct intc_hw_operations aplic_ops = {
>>>       .info                = &aplic_info,
>>> -    .init                = aplic_init,
>>>       .host_irq_type       = &aplic_xen_irq_type,
>>>       .handle_interrupt    = aplic_handle_interrupt,
>>>       .set_irq_type        = aplic_set_irq_type,
>>>   };
>>>   
>>> +static const struct intc_hw_init_ops __initconst aplic_init_ops = {
>>
>> ... I think this needs to use __initconstrel, as ...
>>
>>> +    .ops                 = &aplic_ops,
>>> +    .init                = aplic_init,
>>> +};
>>
>> ... both initialized fields incur a relocation.
> 
> Isn’t it needed only when `aplic_init_ops.{ops,init}` is saved in a 
> variable that doesn’t belong to the `.init` section, so that a potential 
> dereference of already freed memory could occur?

No, that's no different between __init{data,const,constrel}. The issue here
is that at least in PIC mode const global variables with initializers will
go into .data.rel.ro (or alike), not .rodata. That's because this section
should be writable, yet there shouldn't be writable contributions to
.rodata.

Since __initconst{,rel} include section placement, the former of the two
(.init.rodata) should end up r/o, while the latter of the two
(.init.rodata.rel) should again be r/w. Mismatched contributions would
screw up the attributes, and assemblers in the past did (and legitimately
may) warn about such mismatches.

Jan