[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240531143244.GGZlnfjCYalemAZ_Fu@fat_crate.local>
Date: Fri, 31 May 2024 16:32:44 +0200
From: Borislav Petkov <bp@...en8.de>
To: Uros Bizjak <ubizjak@...il.com>
Cc: Borislav Petkov <bp@...nel.org>, X86 ML <x86@...nel.org>,
LKML <linux-kernel@...r.kernel.org>,
Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH 02/14] x86/alternatives: Add nested alternatives macros
On Fri, May 31, 2024 at 04:30:31PM +0200, Uros Bizjak wrote:
> Please don't resurrect the %P modifier, use %c instead.
>
> > +
> > /*
> > * Like alternative_call, but there are two features and respective functions.
> > * If CPU has feature2, function2 is used.
> > @@ -307,6 +376,15 @@ static inline int alternatives_text_reserved(void *start, void *end)
> > : [old] "i" (oldfunc), [new1] "i" (newfunc1), \
> > [new2] "i" (newfunc2), ## input)
> > +#define n_alternative_call_2(oldfunc, newfunc1, ft_flags1, newfunc2, ft_flags2, \
> > + output, input...) \
> > + asm_inline volatile (N_ALTERNATIVE_2("call %P[old]", "call %P[new1]", ft_flags1,\
> > + "call %P[new2]", ft_flags2) \
> > + : output, ASM_CALL_CONSTRAINT \
> > + : [old] "i" (oldfunc), [new1] "i" (newfunc1), \
> > + [new2] "i" (newfunc2), ## input)
>
> Here too, %P should be avoided in favor of %c.
Yeah, will do.
We probably should update our patch checking scripts to catch such
things in the future.
/me adds to todo.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
Powered by blists - more mailing lists