From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1754335AbbCQJhn (ORCPT <rfc822;w@1wt.eu>);
	Tue, 17 Mar 2015 05:37:43 -0400
Received: from cantor2.suse.de ([195.135.220.15]:36066 "EHLO mx2.suse.de"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S932185AbbCQJhS (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 17 Mar 2015 05:37:18 -0400
Date: Tue, 17 Mar 2015 10:35:43 +0100
From: Borislav Petkov <bp@suse.de>
To: Quentin Casasnovas <quentin.casasnovas@oracle.com>
Cc: Oleg Nesterov <oleg@redhat.com>, Dave Hansen <dave.hansen@intel.com>,
        Ingo Molnar <mingo@kernel.org>, Andy Lutomirski <luto@amacapital.net>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Pekka Riikonen <priikone@iki.fi>, Rik van Riel <riel@redhat.com>,
        Suresh Siddha <sbsiddha@gmail.com>,
        LKML <linux-kernel@vger.kernel.org>,
        "Yu, Fenghua" <fenghua.yu@intel.com>, "H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH RFC 2/2] x86/fpu: change xsave_user() and xrestore_user()
 to use __user_insn()
Message-ID: <20150317093543.GC18917@pd.tnic>
References: <54F74F59.5070107@intel.com>
 <20150315164948.GA28149@redhat.com>
 <20150315165036.GC28149@redhat.com>
 <20150316224301.GB14575@chrystal.uk.oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20150316224301.GB14575@chrystal.uk.oracle.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, Mar 16, 2015 at 11:43:01PM +0100, Quentin Casasnovas wrote:
> So I'm really not sure about all the callers, but it seems that this
> instruction can be used to restore more than just the FPU state and I've no
> idea how much can change underneath gcc when we do so.  It "feels" safe
> when saving the CPU state, not sure for the restoring case.

The clobber is to prevent gcc from optimizing accesses around the asm
volatile statement. And as Oleg said, this is user memory so if we want
to touch it, we will have a compiler barrier somewhere around that code.
I certainly hope we do...

-- 
Regards/Gruss,
    Boris.

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