From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1423115AbbD2Nxw (ORCPT ); Wed, 29 Apr 2015 09:53:52 -0400 Received: from mga02.intel.com ([134.134.136.20]:52180 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1422891AbbD2Nxh (ORCPT ); Wed, 29 Apr 2015 09:53:37 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.11,671,1422950400"; d="scan'208";a="702714472" Message-ID: <5540E25F.20303@intel.com> Date: Wed, 29 Apr 2015 06:53:35 -0700 From: Dave Hansen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Fenghua Yu , "H. Peter Anvin" , Ingo Molnar , Thomas Gleixner , Asit K Mallick , Glenn Williamson CC: linux-kernel , x86 Subject: Re: [PATCH Bugfix v2 2/4] x86/xsaves: Define and use user_xstate_size for xstate size in signal context References: <1429678319-61356-1-git-send-email-fenghua.yu@intel.com> <1429678319-61356-3-git-send-email-fenghua.yu@intel.com> In-Reply-To: <1429678319-61356-3-git-send-email-fenghua.yu@intel.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/21/2015 09:51 PM, Fenghua Yu wrote: > +static int copy_to_user_xstate(void __user *buf_fx, struct xsave_struct *xsave) I was thinking about this a bit more. I think uncompacting the xsave state from the kernel buffer in to the user buffer in software is probably a bad idea. It would nice, eventually, to not need to memset() the entire xsave state when we initialize it. It could be a lot bigger some day, and we might start to notice the memset() cost. We can't do this unless we're careful about copying uninitialized parts of the task xstate buffer out to userspace. The whole reason we've gone down this path is that we are !user_has_fpu(), so there is no FPU state in the registers which we can xsave directly. Perhaps we should enable the FPU hardware, restore the state to the registers (from the xstate buffer), and then use xsave_user() to write the user xstate buffer. This *might* even be faster. But, it *is* a slow (and rare) path, so it does not really matter what we do performance-wise. What I've described above should be a lot less code than what we've got now. It makes the hardware do the hard work.