On 07.06.2023 11:19, Andrew Cooper wrote: > On 07/06/2023 10:17 am, Roger Pau Monné wrote: >> On Wed, Jun 07, 2023 at 11:10:27AM +0200, Jan Beulich wrote: >>> On 07.06.2023 11:01, Roger Pau Monne wrote: >>>> Guard it with CONFIG_LIVEPATCH. Note alternatives are applied at boot >>>> using _apply_alternatives(). >>>> >>>> Signed-off-by: Roger Pau Monné <roger....@citrix.com> >>>> Reviewed-by: Julien Grall <jgr...@amazon.com> >>> Reviewed-by: Jan Beulich <jbeul...@suse.com> >>> albeit the implicit ack therein is only on the assumption that (apart >>> from me) it is generally deemed better ... >>> >>>> --- a/xen/arch/x86/alternative.c >>>> +++ b/xen/arch/x86/alternative.c >>>> @@ -358,11 +358,12 @@ static void init_or_livepatch >>>> _apply_alternatives(struct alt_instr *start, >>>> } >>>> } >>>> >>>> -void init_or_livepatch apply_alternatives(struct alt_instr *start, >>>> - struct alt_instr *end) >>>> +#ifdef CONFIG_LIVEPATCH >>> ... to have the #ifdef than the init_or_livepatch attribute. >> But the init_or_livepatch attribute doesn't remove the function when >> !CONFIG_LIVEPATCH, so it's not a replacement for the ifdef. >> >> IOW: it's my understanding that the purpose of init_or_livepatch is to >> add the __init attribute if livepatch is not enabled, but >> apply_alternatives() should never have the __init attribute because >> it's solely used by livepatch, it's not used at boot. > > For context, Jan you missed the MISRA call yesterday where this was > identified as an emitted-but-undeferenced function.
Ah, this helps. Thanks, Jan
