Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp2968418imm; Thu, 17 May 2018 00:45:58 -0700 (PDT) X-Google-Smtp-Source: AB8JxZoGldG0/LNCAE82ABj2lNWVY5fCxMs/YpTlZAaO6ummnG6eI4z8fbDr3ESWPx6rlVkOKFmh X-Received: by 2002:a17:902:74c6:: with SMTP id f6-v6mr4242360plt.7.1526543158863; Thu, 17 May 2018 00:45:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526543158; cv=none; d=google.com; s=arc-20160816; b=qJHe6BKpqZGexawAaziEJ7YVZFM4WlNj5+M7n370R/FYIrPTw4e7YwIGGxX7DkR5H8 U9SY/RLV7LM7xNozIg0tELCPjG1SxyXOtJRG7bk8CiHzOUq9QflZfmUID6DbtXjtDOez 1PbIXdZHTDPtdoYpojZNyiHal+lTa2bDKUI1JhGic5Jcbhl04UdlaUrW6Z5AaEko3hLu 2y+hIpGl5ZALJ3URGhZ4Z4ZKsTi+eRmIQrdlJm1AYmNvqr6ntXDXjUDYYGWeyfIaIlix IyfillWIfPWU2cSaZS26AVhJ3MUvbVJWXWbWClVCDTrrE/j4nsLLitq9ZC2y9yRLTbBO ZnZA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=sXveWMCKKrM0+HDiL3455U5yklXzsU9WDqPjohcokKs=; b=gg3n9fCTVaQHc5sBwYujA36zenzANT4E3C8cV/uiAann45hz2lTrznp/agaEiHhcXf y9Fb8B9a+2YLqTPJXrTEpZucjCeApkzrRHh0lwH1Z+TefeJJlFaAJtgps0XCwNouziLN HuqjZyCBijn+euDRkIwciGmCkqpsL0yb+IZkUbLK79AWNZU4NDNvy7j0rlQraOD/2ODL 8AdvxxkWjRKcl+bkfaucvqqTMelkCMf877S474fsy2Ezh7VA1SNSDO+6LDPGxzk1SkIW rZNShYk8aWbqJtpzjtQwDcZodPP+HBRSEb7OXgbLcmKMPaowGvcbgREY/anpkoeGSmXL jM/g== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=sQbEs2ug; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w65-v6si4698065pfa.18.2018.05.17.00.45.44; Thu, 17 May 2018 00:45:58 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=sQbEs2ug; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752631AbeEQHoJ (ORCPT + 99 others); Thu, 17 May 2018 03:44:09 -0400 Received: from bombadil.infradead.org ([198.137.202.133]:46652 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752162AbeEQHoD (ORCPT ); Thu, 17 May 2018 03:44:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=sXveWMCKKrM0+HDiL3455U5yklXzsU9WDqPjohcokKs=; b=sQbEs2ugiT9ZCzTaJxLiimy+P P5vnZs+73lXe6xYSdhx8MOiDI4UO4HyNtejBP8W7EUtzD5CmLvsr0bswKJxw6PFZfg+rw3/F7dxld 0+RV9lphyvNaklTLa+bQa37hKxK3U/Gej8ngBNXJih3EqtfzogSl9ulMscwXph8gm0tb/JpilfQeB 2JFVQOSmSoZLqUP+ieQh6hATMbOpl9kNGsOJwOeZr1r4ehHNYIZykwDFRrIIzmoxNVJ860if5dV4E pmEjo6cOzV6OOF7Ybi5CFcIdL2S2Xrw5HxB+q5ME36xKbImwcMxg1M6uIeI6rtOvYjnHPztKz51bn R6lZv4G3Q==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=hirez.programming.kicks-ass.net) by bombadil.infradead.org with esmtpsa (Exim 4.90_1 #2 (Red Hat Linux)) id 1fJDZE-0002ji-Bx; Thu, 17 May 2018 07:43:16 +0000 Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 06A432029F86E; Thu, 17 May 2018 09:43:14 +0200 (CEST) Date: Thu, 17 May 2018 09:43:14 +0200 From: Peter Zijlstra To: Boqun Feng Cc: Mathieu Desnoyers , "Paul E. McKenney" , Andy Lutomirski , Dave Watson , linux-kernel , linux-api , Paul Turner , Andrew Morton , Russell King , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Andrew Hunter , Andi Kleen , Chris Lameter , Ben Maurer , rostedt , Josh Triplett , Linus Torvalds , Catalin Marinas , Will Deacon , Michael Kerrisk , Joel Fernandes , Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , linuxppc-dev Subject: Re: [PATCH 07/14] powerpc: Add support for restartable sequences Message-ID: <20180517074313.GK12217@hirez.programming.kicks-ass.net> References: <20180430224433.17407-1-mathieu.desnoyers@efficios.com> <20180430224433.17407-8-mathieu.desnoyers@efficios.com> <20180516161837.GI12198@hirez.programming.kicks-ass.net> <112970629.1913.1526501596485.JavaMail.zimbra@efficios.com> <20180517011949.GA1121@tardis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180517011949.GA1121@tardis> User-Agent: Mutt/1.9.5 (2018-04-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 17, 2018 at 09:19:49AM +0800, Boqun Feng wrote: > On Wed, May 16, 2018 at 04:13:16PM -0400, Mathieu Desnoyers wrote: > > and that x86 calls it from syscall_return_slowpath() (which AFAIU is > > now used in the fast-path since KPTI), I wonder where we should call > > So we actually detect this after the syscall takes effect, right? I > wonder whether this could be problematic, because "disallowing syscall" > in rseq areas may means the syscall won't take effect to some people, I > guess? It doesn't really matter I suspect, the important part is the program getting killed. I agree that doing it on sysenter is slightly nicer, but I'll take sysexit if that's what it takes. > > this on PowerPC ? I was under the impression that PowerPC return to > > userspace fast-path was not calling C code unless work flags were set, > > but I might be wrong. > > > > I think you're right. So we have to introduce callsite to rseq_syscall() > in syscall path, something like: > > diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S > index 51695608c68b..a25734a96640 100644 > --- a/arch/powerpc/kernel/entry_64.S > +++ b/arch/powerpc/kernel/entry_64.S > @@ -222,6 +222,9 @@ system_call_exit: > mtmsrd r11,1 > #endif /* CONFIG_PPC_BOOK3E */ > > + addi r3,r1,STACK_FRAME_OVERHEAD > + bl rseq_syscall > + > ld r9,TI_FLAGS(r12) > li r11,-MAX_ERRNO > andi. r0,r9,(_TIF_SYSCALL_DOTRACE|_TIF_SINGLESTEP|_TIF_USER_WORK_MASK|_TIF_PERSYSCALL_MASK) > > But I think it's important for us to first decide where (before or after > the syscall) we do the detection. The important thing is the processed getting very dead. Either sysenter or sysexit gets that done.