Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp157806ybz; Tue, 21 Apr 2020 17:36:22 -0700 (PDT) X-Google-Smtp-Source: APiQypI+S8+WPrMkXbRCLVNct8fH1nTYYGMRs9mTlXpFhlDDndvvnwOmUBLYvMq5ws2+CRcnnAQx X-Received: by 2002:aa7:d892:: with SMTP id u18mr20065964edq.156.1587515782797; Tue, 21 Apr 2020 17:36:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587515782; cv=none; d=google.com; s=arc-20160816; b=EM3GicWh40yIBTmmF6TUHTQaEfonDi1UbsKn6byf7+QU9qjuMBif4euQbO85mQwA8d fqSR0qhNOif8q4T9NFLTcFsLI5SIzJfx/00C+E2U4ADbR2wdX108rmftiRwl7tbha2xi Aa2C87tz5Rnw6tY5YjABI4TCLK1Twm7o13TyloSp1Adr05S30/74haN7k/6VchasrR8Y VY8HqvQ9DiPgZDVpEJHqySI+ibSPoIJyRE7a5Enb+NMCbqaORT7dJ7FjjIegIISK5tDr Fx8C4ziB3Q7TGheeEwJKbq/rPSxyZuxR5qByRZS4uS6ox7VpxYL2Mw0sPIM15Q3ST2uJ mczw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=JfetvEGLcuKDQflBkx0XZFom0iB5hKrscoN2GeR06RM=; b=OzSNofbK1RUg8uLzQmtpPNhn2+MDlQXFVopYi1pDt80rah6HvI8aOgAw2hl8FJwejn j1hJS4fl5D8FssD5c3Ravh5VjSjQksWIF+E30zvCLOyygu1sTMW/dWH6zzTe/OiPsLq9 M3zyXeZRefoS6SK/J85IR86707j8Ao/LboBJWaoBL52ra0ieuoBVai/g9MU5iz6ZqILS LyCcH6jNYom+5krokFgeCODgTEBy7w73LfV51OOFI6v6q4q9aXbztYjFieQggzWlrsX8 zfVPgyPzOTNfoy4k47GEhLGR0B7srvL2619KXE2IJpgGTMLb2c7ZTI00Ih2DaYo1n5Ex DzGQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i18si2754500ejz.35.2020.04.21.17.35.50; Tue, 21 Apr 2020 17:36:22 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726284AbgDVAdt (ORCPT + 99 others); Tue, 21 Apr 2020 20:33:49 -0400 Received: from mail.kernel.org ([198.145.29.99]:37606 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726012AbgDVAds (ORCPT ); Tue, 21 Apr 2020 20:33:48 -0400 Received: from oasis.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 2F8612070B; Wed, 22 Apr 2020 00:33:47 +0000 (UTC) Date: Tue, 21 Apr 2020 20:33:45 -0400 From: Steven Rostedt To: Peter Zijlstra Cc: tglx@linutronix.de, jpoimboe@redhat.com, linux-kernel@vger.kernel.org, x86@kernel.org, mhiramat@kernel.org, mbenes@suse.cz, jthierry@redhat.com, alexandre.chartre@oracle.com Subject: Re: [PATCH v5 04/17] x86,ftrace: Fix ftrace_regs_caller() unwind Message-ID: <20200421203345.4e165c4b@oasis.local.home> In-Reply-To: <20200416115118.749606694@infradead.org> References: <20200416114706.625340212@infradead.org> <20200416115118.749606694@infradead.org> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Peter, After looking at the code, I realized that the only possible way to do the "direct call" part, is if the direct function helper is executed there. All other ftrace_ops, will not call that path. I added a trampoline that points to ftrace_regs_caller to the direct ftrace_ops, to force it never to allocate its own trampoline, and thus no created trampoline should ever do the jump for a direct caller. By doing this, I was able to move the code around to be a bit simpler, and not need the double modifications (the double ret). Of course, if any created trampoline were to touch the ORIG_RAX, then it would crash. We could always nop that compare in the created trampoline if that is a concern. Anyway, I added the below patch on top of your patches and it appears to work. Thoughts? -- Steve diff --git a/arch/x86/kernel/ftrace.c b/arch/x86/kernel/ftrace.c index 867c126ddabe..2e11250d5647 100644 --- a/arch/x86/kernel/ftrace.c +++ b/arch/x86/kernel/ftrace.c @@ -367,13 +367,6 @@ create_trampoline(struct ftrace_ops *ops, unsigned int *tramp_size) if (WARN_ON(ret < 0)) goto fail; - if (ops->flags & FTRACE_OPS_FL_SAVE_REGS) { - ip = trampoline + (ftrace_regs_caller_ret - ftrace_regs_caller); - ret = probe_kernel_read(ip, (void *)retq, RET_SIZE); - if (WARN_ON(ret < 0)) - goto fail; - } - /* * The address of the ftrace_ops that is used for this trampoline * is stored at the end of the trampoline. This will be used to diff --git a/arch/x86/kernel/ftrace_64.S b/arch/x86/kernel/ftrace_64.S index 9738ed23964e..1f2afaa8f71f 100644 --- a/arch/x86/kernel/ftrace_64.S +++ b/arch/x86/kernel/ftrace_64.S @@ -241,22 +241,9 @@ SYM_INNER_LABEL(ftrace_regs_call, SYM_L_GLOBAL) */ movq ORIG_RAX(%rsp), %rax testq %rax, %rax - jz 1f + jnz 1f - /* Swap the flags with orig_rax */ - movq MCOUNT_REG_SIZE(%rsp), %rdi - movq %rdi, MCOUNT_REG_SIZE-8(%rsp) - movq %rax, MCOUNT_REG_SIZE(%rsp) - - restore_mcount_regs 8 - /* Restore flags */ - popfq - -SYM_INNER_LABEL(ftrace_regs_caller_ret, SYM_L_GLOBAL); - UNWIND_HINT_RET_OFFSET - jmp ftrace_epilogue - -1: restore_mcount_regs + restore_mcount_regs /* Restore flags */ popfq @@ -267,8 +254,19 @@ SYM_INNER_LABEL(ftrace_regs_caller_ret, SYM_L_GLOBAL); * to the return. */ SYM_INNER_LABEL(ftrace_regs_caller_end, SYM_L_GLOBAL) + UNWIND_HINT_RET_OFFSET jmp ftrace_epilogue + /* Swap the flags with orig_rax */ +1: movq MCOUNT_REG_SIZE(%rsp), %rdi + movq %rdi, MCOUNT_REG_SIZE-8(%rsp) + movq %rax, MCOUNT_REG_SIZE(%rsp) + + restore_mcount_regs 8 + /* Restore flags */ + popfq + jmp ftrace_epilogue + SYM_FUNC_END(ftrace_regs_caller) diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c index 041694a1eb74..8f540eef7511 100644 --- a/kernel/trace/ftrace.c +++ b/kernel/trace/ftrace.c @@ -2399,6 +2399,13 @@ struct ftrace_ops direct_ops = { .flags = FTRACE_OPS_FL_IPMODIFY | FTRACE_OPS_FL_RECURSION_SAFE | FTRACE_OPS_FL_DIRECT | FTRACE_OPS_FL_SAVE_REGS | FTRACE_OPS_FL_PERMANENT, + /* + * By declaring the main trampoline as this trampoline + * it will never have one allocated for it. This is fine + * as this should only be used if we are in the + * ftrace_ops_list function. + */ + .trampoline = FTRACE_REGS_ADDR, }; #endif /* CONFIG_DYNAMIC_FTRACE_WITH_DIRECT_CALLS */