lkml.org 
[lkml]   [2015]   [Oct]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH] x86/cpu: Fix MSR value truncation issue
On Fri, Oct 30, 2015 at 11:59:39AM -0700, Andy Lutomirski wrote:
> Is this with or without:
>
> commit 47edb65178cb7056c2eea0b6c41a7d8c84547192
> Author: Andy Lutomirski <luto@kernel.org>
> Date: Thu Jul 23 12:14:40 2015 -0700
>
> x86/asm/msr: Make wrmsrl() a function

with.

I'm playing ontop of 4.3-rc7.

> If that patch is applied, then I think that gcc is just being dumb and

Huh, why?

gcc is actually being smart by completely avoiding the shift to the
upper bits and puts those directly into %edx and sparse simply says that
we're truncating some bits.

I actually think that sparse is correct in saying that some bits are
going to be zeroed out even though we want that here.

> that we should consider tweaking wrmsrl to avoid generating the
> warning. Maybe change (u32)val to (u32)(val & 0xffffffffull)?

That works.

> I don't see why we should uglify the caller when the problem is some
> combination of gcc and the wrmsrl implementation.

Why uglify?

We're basically making explicit that we write the high 32-bits with the
SYSCALL and SYSRET CS and SS and we set the low 32-bit explicitly to 0:

wrmsr(MSR_STAR, 0, (__USER32_CS << 16) | __KERNEL_CS);

versus setting the low 32-bits to zero *implicitly*:

wrmsrl(MSR_STAR, ((u64)__USER32_CS)<<48 | ((u64)__KERNEL_CS)<<32);

due to that shifting to the left filling up the 32-bit with zeroes.

--
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.


\
 
 \ /
  Last update: 2015-10-30 20:41    [W:1.300 / U:0.080 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site