Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932887AbbLRIcn (ORCPT ); Fri, 18 Dec 2015 03:32:43 -0500 Received: from mail-wm0-f45.google.com ([74.125.82.45]:36099 "EHLO mail-wm0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753736AbbLRIcl (ORCPT ); Fri, 18 Dec 2015 03:32:41 -0500 Date: Fri, 18 Dec 2015 09:32:36 +0100 From: Ingo Molnar To: Andy Lutomirski Cc: Dave Hansen , Oleg Nesterov , Thomas Gleixner , Borislav Petkov , Brian Gerst , "linux-kernel@vger.kernel.org" , "H. Peter Anvin" , Linus Torvalds Subject: Re: Rethinking sigcontext's xfeatures slightly for PKRU's benefit? Message-ID: <20151218083236.GA29790@gmail.com> References: <56736BD1.5080700@linux.intel.com> <5673750B.606@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3423 Lines: 82 * Andy Lutomirski 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? > > Yes, to a very limited extent: SA_ONSTACK. > > > > > >> 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." > > > > You win this round :) > > So maybe we should have a mask of xfeatures that aren't cleared on > signal delivery (e.g. PKRU, perhaps) and that are, by default, > preserved across signal returns. So the principle is this: signals are conceptually like creating a new thread of execution, and that's a very powerful programming concept, like fork() or pthread_create() are powerful concepts. So we definitely want to keep that default behavior, and I don't think we want to deviate from that for typical new extended CPU context features, even if signal delivery slows down as a result. But we've been arguing about 'lightweight signals' for up to two decades that I can remember. (The first such suggestion was to not save the FPU state, back when FPU saves were ridiculously slow compared to other parts of saving/restoring a context.) So having a well-enumerated, extensible opt-in mask (which defaults to 'all state saved') that allows smart signal handlers to skip the save/restore of certain CPU context components would be acceptable I think. But I'd still expect this to be limited to closely coded, specialistic signal handlers - as the trend goes against such type of specialization: compilers and runtime environments do take advantage of new CPU features so if you want to have an 'easy to use' signal handler, you should use the default one. I'd not be surprised if large-scale signal users like Valgrind could benefit. > > I'm sure we can preserve it, we just need to be _careful_. > > Right. > > How much does XSAVEOPT help here? IOW if we're careful to save to the same > place we restored from and we don't modify the state in the mean time, how much > of the time do we save? In the best case, I guess we save the memory writes but > not the reads? So I'd not design new signal interfaces around current behavior, I'd design them for the existing patterns (which center around programming ease of use) - with opt-in, performance-enhancing specializations. Thanks, Ingo -- 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/