All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Hansen <dave.hansen@intel.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	X86 ML <x86@kernel.org>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Rik van Riel <riel@redhat.com>,
	Suresh Siddha <sbsiddha@gmail.com>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Fenghua Yu <fenghua.yu@intel.com>,
	Oleg Nesterov <oleg@redhat.com>
Subject: Re: [PATCH 01/17] x86, fpu: wrap get_xsave_addr() to make it safer
Date: Tue, 24 Mar 2015 17:12:09 -0700	[thread overview]
Message-ID: <5511FD59.3040503@intel.com> (raw)
In-Reply-To: <CALCETrUxfd8brhWzBJSsSA=M1OHOSUWtu73gosPGZV9QgM6Z4Q@mail.gmail.com>

On 03/24/2015 04:52 PM, Andy Lutomirski wrote:
> On Tue, Mar 24, 2015 at 4:42 PM, Dave Hansen <dave.hansen@intel.com> wrote:
>> On 03/24/2015 03:28 PM, Andy Lutomirski wrote:
>>> Your function appears to be getting it for write (I assume that's what
>>> the unlazy_fpu is for), so I'd rather have it called
>>> tsk_get_xsave_field_for_write or something like that.
>>
>> It should be entirely read-only.
>>
>> For MPX (the only user of get_xsave_addr() iirc), we are only worried
>> about getting the status codes (and addresses) out of the bndstatus
>> register and making sure that the kernel-recorded bounds directory
>> address matches the bndcfgu (configuration) register.
>>
>> We don't ever write to the registers.
> 
> So why are you unlazying it?

Oleg actually suggested it.

> IIUC, the xstae for current can be in one of three logical states:
> 
> 1. Live in CPU regs.  The in-memory copy is garbage and the state is
> in CPU regs.
> 2. Lazy.  The in-memory copy and the CPU regs match.  Writing to
> either copy is illegal.
> 3. In memory only.  Writing to the in-memory copy is safe.
> 
> IIUC, you want to read the xstate, do you're okay with #2 or #3.  This
> would be tsk_get_xsave_field_for_read in my terminology.
> 
> If you want to write the xstate, you'd need to be in state #3, which
> would be tsk_get_xsave_field_for_write.
> 
> IIUC, unlazy_fpu just moves from from state 2 to 3.

I won't completely claim to understand what's going on with the FPU
code, but I think your analysis is a bit off.

unlazy_fpu() does __save_init_fpu() which (among other things) calls
xsave to dump the CPU registers to memory.  That doesn't make any sense
to do if "The in-memory copy and the CPU regs match."

IOW, unlazy_fpu() is called when the in-memory copy is garbage and takes
us to a state where we can look at the in-memory copy.

  reply	other threads:[~2015-03-25  0:12 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1427235664-25318-1-git-send-email-dave.hansen@intel.com>
     [not found] ` <1427235664-25318-2-git-send-email-dave.hansen@intel.com>
2015-03-24 22:28   ` [PATCH 01/17] x86, fpu: wrap get_xsave_addr() to make it safer Andy Lutomirski
2015-03-24 23:42     ` Dave Hansen
2015-03-24 23:52       ` Andy Lutomirski
2015-03-25  0:12         ` Dave Hansen [this message]
2015-03-25  0:18           ` Andy Lutomirski
2015-03-25  0:20             ` Andy Lutomirski
2015-03-25  1:01             ` Rik van Riel
2015-03-25  9:08               ` Borislav Petkov
2015-03-25 14:15                 ` Oleg Nesterov
2015-03-25 12:56               ` Oleg Nesterov
2015-03-25 12:45             ` Oleg Nesterov
2015-03-25 14:28               ` Dave Hansen
2015-03-25 17:11                 ` Oleg Nesterov
2015-03-26 18:33 [PATCH 00/17] x86, mpx updates for 4.1 (take 2) Dave Hansen
2015-03-26 18:33 ` [PATCH 01/17] x86, fpu: wrap get_xsave_addr() to make it safer Dave Hansen
2015-03-27 15:15   ` Borislav Petkov
2015-03-27 16:35     ` Dave Hansen
2015-03-27 18:57   ` Oleg Nesterov
  -- strict thread matches above, loose matches on Subject: below --
2015-03-27 21:52 [PATCH 00/17] x86, mpx updates for 4.1 (take 3) Dave Hansen
2015-03-27 21:52 ` [PATCH 01/17] x86, fpu: wrap get_xsave_addr() to make it safer Dave Hansen
2015-04-22 18:27 [PATCH 00/17] x86, mpx updates for 4.2 (take 5) Dave Hansen
2015-04-22 18:27 ` [PATCH 01/17] x86, fpu: wrap get_xsave_addr() to make it safer Dave Hansen
2015-04-25  9:31   ` Borislav Petkov
2015-05-05 17:27     ` Borislav Petkov
2015-05-08 17:42       ` Dave Hansen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5511FD59.3040503@intel.com \
    --to=dave.hansen@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=fenghua.yu@intel.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=mingo@redhat.com \
    --cc=oleg@redhat.com \
    --cc=riel@redhat.com \
    --cc=sbsiddha@gmail.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.