Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966120AbbLRCxE (ORCPT ); Thu, 17 Dec 2015 21:53:04 -0500 Received: from mga03.intel.com ([134.134.136.65]:32519 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932459AbbLRCxB (ORCPT ); Thu, 17 Dec 2015 21:53:01 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,444,1444719600"; d="scan'208";a="873954198" Subject: Re: Rethinking sigcontext's xfeatures slightly for PKRU's benefit? To: Andy Lutomirski References: <56736BD1.5080700@linux.intel.com> Cc: Andy Lutomirski , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , Thomas Gleixner , "linux-kernel@vger.kernel.org" , Brian Gerst , Oleg Nesterov From: Dave Hansen Message-ID: <5673750B.606@linux.intel.com> Date: Thu, 17 Dec 2015 18:52:59 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2464 Lines: 60 On 12/17/2015 06:32 PM, Andy Lutomirski wrote: > On Thu, Dec 17, 2015 at 6:13 PM, Dave Hansen wrote: >> But what about the register state when delivering a signal? Don't we >> set the registers to the init state? Do we need to preserve PKRU state >> instead of init'ing it? The init state _is_ nice here because it is >> permissive allows us to do something useful no matter what PKRU gets set to. > > I think we leave the extended regs alone. Don't we? > > I think that, for most signals, we want to leave PKRU as is, > especially for things that aren't SIGSEGV. For SIGSEGV, maybe we want > an option to reset PKRU on delivery (and then set the flag to restore > on return?). Is there some precedent for doing the state differently for different signals? >> Well, the signal handler isn't necessarily going to clobber it, but the >> delivery code already clobbers it when going to the init state. > > Can you point to that code? handle_signal() -> fpu__clear() The comment around it says: "Ensure the signal handler starts with the new fpu state." >>> We have _fpx_sw_bytes.xfeatures and _xstate._header.xfeatures. They >>> appear to do more or less the same thing. >> >> I thought the _fpx_sw_bytes were only for 32-bit (or FXSAVE/FXRSTOR?). > > I thought they were everywhere. fpu/signal.c looks that way to me. I > could be missing something -- this code isn't the most straightforward > in the world. I think there's some extra space on the ia32 frame for this stuff, but some clarity from someone who knows the history would be appreciated. >> Not a huge deal, but something we want to think about, especially as it >> pertains to the init/modified optimizations. > > Fair point. FWIW, I don't think that sigreturn performance matters > all that much, so if we inadvertently lose some of the optimizations, > it may not be the end of the world. Once we lose the init optimization, we're sunk for good. We never get it back until we restore the init state again. Having it in the init state can save writing the state at XSAVE time, which can now save up to ~2k of writes at each context switch. I'm sure we can preserve it, we just need to be _careful_. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/