[PATCH for 4.4.y] x86/vdso: Fix lsl operand order

[PATCH for 4.4.y] x86/vdso: Fix lsl operand order

[Nobuhiro Iwamatsu]

From: Samuel Neves <sneves@dei.uc.pt>

commit e78e5a91456fcecaa2efbb3706572fe043766f4d upstream.

In the __getcpu function, lsl is using the wrong target and destination
registers. Luckily, the compiler tends to choose %eax for both variables,
so it has been working so far.

Fixes: a582c540ac1b ("x86/vdso: Use RDPID in preference to LSL when available")
Signed-off-by: Samuel Neves <sneves@dei.uc.pt>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Andy Lutomirski <luto@kernel.org>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20180901201452.27828-1-sneves@dei.uc.pt
Signed-off-by: Nobuhiro Iwamatsu (CIP) <nobuhiro1.iwamatsu@toshiba.co.jp>
---
 arch/x86/include/asm/vgtod.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/vgtod.h b/arch/x86/include/asm/vgtod.h
index 51e7533bbf79e..ef342818fcf11 100644
--- a/arch/x86/include/asm/vgtod.h
+++ b/arch/x86/include/asm/vgtod.h
@@ -86,7 +86,7 @@ static inline unsigned int __getcpu(void)
 	 *
 	 * If RDPID is available, use it.
 	 */
-	alternative_io ("lsl %[p],%[seg]",
+	alternative_io ("lsl %[seg],%[p]",
 			".byte 0xf3,0x0f,0xc7,0xf8", /* RDPID %eax/rax */
 			X86_FEATURE_RDPID,
 			[p] "=a" (p), [seg] "r" (__PER_CPU_SEG));
-- 
2.26.0

Re: [PATCH for 4.4.y] x86/vdso: Fix lsl operand order

[Greg KH]

On Wed, Apr 08, 2020 at 05:24:30PM +0900, Nobuhiro Iwamatsu wrote:
> From: Samuel Neves <sneves@dei.uc.pt>
> 
> commit e78e5a91456fcecaa2efbb3706572fe043766f4d upstream.
> 
> In the __getcpu function, lsl is using the wrong target and destination
> registers. Luckily, the compiler tends to choose %eax for both variables,
> so it has been working so far.
> 
> Fixes: a582c540ac1b ("x86/vdso: Use RDPID in preference to LSL when available")
> Signed-off-by: Samuel Neves <sneves@dei.uc.pt>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> Acked-by: Andy Lutomirski <luto@kernel.org>
> Cc: stable@vger.kernel.org
> Link: https://lkml.kernel.org/r/20180901201452.27828-1-sneves@dei.uc.pt
> Signed-off-by: Nobuhiro Iwamatsu (CIP) <nobuhiro1.iwamatsu@toshiba.co.jp>
> ---
>  arch/x86/include/asm/vgtod.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 

What about 4.9?  I can't take a patch for 4.4 without also it being in
newer kernels.

ANd always cc: all the people involved in a patch, let them have a say
if this is ok or not.

Please fix up and resend for both trees.

thanks,

greg k-h

RE: [PATCH for 4.4.y] x86/vdso: Fix lsl operand order

[nobuhiro1.iwamatsu]

Hi,

> -----Original Message-----
> From: Greg KH [mailto:greg@kroah.com]
> Sent: Friday, April 10, 2020 5:42 PM
> To: iwamatsu nobuhiro(岩松 信洋 □ＳＷＣ◯ＡＣＴ) <nobuhiro1.iwamatsu@toshiba.co.jp>
> Cc: stable@vger.kernel.org
> Subject: Re: [PATCH for 4.4.y] x86/vdso: Fix lsl operand order
> 
> On Wed, Apr 08, 2020 at 05:24:30PM +0900, Nobuhiro Iwamatsu wrote:
> > From: Samuel Neves <sneves@dei.uc.pt>
> >
> > commit e78e5a91456fcecaa2efbb3706572fe043766f4d upstream.
> >
> > In the __getcpu function, lsl is using the wrong target and destination
> > registers. Luckily, the compiler tends to choose %eax for both variables,
> > so it has been working so far.
> >
> > Fixes: a582c540ac1b ("x86/vdso: Use RDPID in preference to LSL when available")
> > Signed-off-by: Samuel Neves <sneves@dei.uc.pt>
> > Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> > Acked-by: Andy Lutomirski <luto@kernel.org>
> > Cc: stable@vger.kernel.org
> > Link: https://lkml.kernel.org/r/20180901201452.27828-1-sneves@dei.uc.pt
> > Signed-off-by: Nobuhiro Iwamatsu (CIP) <nobuhiro1.iwamatsu@toshiba.co.jp>
> > ---
> >  arch/x86/include/asm/vgtod.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> 
> What about 4.9?  I can't take a patch for 4.4 without also it being in
> newer kernels.
> 
> ANd always cc: all the people involved in a patch, let them have a say
> if this is ok or not.
> 
> Please fix up and resend for both trees.

OK, I will fix this patch and resend.
Thanks for your comment.

Nobuhiro