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. ~Andrew
