Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp7398144imu; Tue, 22 Jan 2019 05:30:41 -0800 (PST) X-Google-Smtp-Source: ALg8bN6kpTj8AA7hrrFRlaQj5qJyaozTIoMG84gHyfLPv0aIzZX9Ip3RaptCJqNb7zdE7UmdtDEy X-Received: by 2002:a17:902:bb05:: with SMTP id l5mr34868855pls.230.1548163841056; Tue, 22 Jan 2019 05:30:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548163841; cv=none; d=google.com; s=arc-20160816; b=zr8T7YulXpQideBp3ep4l7DLqcKIdazYGZKcVg96YGZwN/r+BfqY0kYOUNvXtWkVdp hI2B6E6er1Bz/Q5Ld2MHvJQi/zpq3ghK8x+bDmYfXe986dPKvdbK4B3uCdzncD0b/k+e qF5HSIYqS8BZHWirKVduYstErjxSNbZEJTNFhUOe5yOtEKi3xztalqufnJU1IXYwemrc 0WmQSvKmMw4SA69ikS57znFyfwQSMZVt8sjpsKb6S+E95ZPdtaPTpmU2djb7e/GwPyYy tFllCXY7hHkenAfqpO0k8ZkzCAeMpRLbIrmaWVf8ct3tAB7D88bJEzK/Tl4wYS4FiBwF 5eZA== 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; bh=fVWQxDopqdk/R3Gr+n0kb25MsRcMNw7dfo97nCJCWJQ=; b=E+ZGzmUUhiNO62Qt2NPdY4WimKIAuWKH+Yiww5ZKEoSHsOKP0gGMzCzO8ziioffo+4 KB6xMxgoc82K4Pm+4hzhg24FOPjfDFQbcSd/qgBIfD5FnHw0fXxEmg0ywmGe6yJi3bAr /e071l/5EfQfj9/m78WlCYykeUhDodVj+KhYJmY/bQD6T0eg1svZuglaX9NFDn4kGEMb HMA00lNIEjO24xXos8mr7CO9ms5xyzVXNfzWXV0rW51gbdTuQpkQFrQRdU7FDJwhi0PJ pn6C/NY3PvIuf8e53Lv1jFKXxv3oIevEAon/LcN/BMC0Le2FKZ/gp6CRNDUW+wjdKzYQ y2Lg== ARC-Authentication-Results: i=1; mx.google.com; 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 11si15963140pgs.126.2019.01.22.05.30.22; Tue, 22 Jan 2019 05:30:41 -0800 (PST) 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; 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 S1728426AbfAVN2e (ORCPT + 99 others); Tue, 22 Jan 2019 08:28:34 -0500 Received: from verein.lst.de ([213.95.11.211]:36451 "EHLO newverein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727936AbfAVN2e (ORCPT ); Tue, 22 Jan 2019 08:28:34 -0500 Received: by newverein.lst.de (Postfix, from userid 2005) id 782DA6FA7F; Tue, 22 Jan 2019 14:28:32 +0100 (CET) Date: Tue, 22 Jan 2019 14:28:32 +0100 From: Torsten Duwe To: Julien Thierry Cc: Mark Rutland , Will Deacon , Catalin Marinas , Steven Rostedt , Josh Poimboeuf , Ingo Molnar , Ard Biesheuvel , Arnd Bergmann , AKASHI Takahiro , Amit Daniel Kachhap , "Singh, Balbir" , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, live-patching@vger.kernel.org Subject: Re: [PATCH v7 2/3] arm64: implement ftrace with regs Message-ID: <20190122132832.GB16778@lst.de> References: <20190118163736.6A99268CEB@newverein.lst.de> <20190118163908.E338E68D93@newverein.lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 22, 2019 at 10:18:17AM +0000, Julien Thierry wrote: > Hi Torsten, > > A few suggestions below. > > > +#ifdef CONFIG_DYNAMIC_FTRACE_WITH_REGS > > +#define ARCH_SUPPORTS_FTRACE_OPS 1 > > +#define REC_IP_BRANCH_OFFSET AARCH64_INSN_SIZE > > +/* All we need is some magic value. Simply use "_mCount:" */ > > Nit: Should the casing be "_mcount" ? No! The string makes it clear what it's supposed to be and the peculiar casing makes it unique and leaves no doubt were it came from. So whenever you see this register value in a crash dump you don't have to wonder about weird linkage errors, as it surely did not originate from a symtab. > > +#define MCOUNT_ADDR (0x5f6d436f756e743a) > > +#else > > +#define REC_IP_BRANCH_OFFSET 0 > > +#define MCOUNT_ADDR ((unsigned long)_mcount) > > +#endif > > + > > #ifndef __ASSEMBLY__ > > #include > > > > --- a/arch/arm64/kernel/entry-ftrace.S > > +++ b/arch/arm64/kernel/entry-ftrace.S > > @@ -10,6 +10,7 @@ > > */ > > > > #include > > +#include > > #include > > #include > > #include ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > + > > +ENTRY(ftrace_common) > > + > > + mov x3, sp /* pt_regs are @sp */ > > + ldr_l x2, function_trace_op, x0 > > + mov x1, x9 /* parent IP */ > > + sub x0, lr, #8 /* function entry == IP */ > > The #8 is because we go back two instructions right? Can we use > #(AARCH64_INSN_SIZE * 2) instead? Hmm, was already included, so why not. (same below) > > +#ifdef CONFIG_DYNAMIC_FTRACE_WITH_REGS > > +int ftrace_modify_call(struct dyn_ftrace *rec, unsigned long old_addr, > > + unsigned long addr) > > +{ > > + unsigned long pc = rec->ip + REC_IP_BRANCH_OFFSET; > > + u32 old, new; > > + > > + old = aarch64_insn_gen_branch_imm(pc, old_addr, true); > > + new = aarch64_insn_gen_branch_imm(pc, addr, true); > > The last argument of aarch64_insn_gen_branch_imm() is an enum, not a > boolean. > > You should use AARCH64_INSN_BRANCH_LINK here which happens to be equal to 1. That's what you get when you keep copying code... Good catch, thanks! > > + * initially; the NOPs are already there. So instead, > > + * put the LR saver there ahead of time, in order to avoid > > + * any race condition over patching 2 instructions. > > + */ > > + if (IS_ENABLED(CONFIG_DYNAMIC_FTRACE_WITH_REGS) && > > + addr == MCOUNT_ADDR) { > > This works, however it feels a bit weird since core code asked to > generate a NOP but not only we don't generate it but we put another > instruction instead. It's not the first time weird x86 sets the standards and all others need workarounds. But here it just came handy to abuse this call :-) > I think it would be useful to state that the replacement of mcount calls > by nops is only ever done once at system initialization. > > Or maybe have a intermediate function: > > static int ftrace_setup_patchable_entry(unsigned long addr) > { > u32 old, new; > > old = aarch64_insn_gen_nop(); > new = MOV_X9_X30; > pc -= REC_IP_BRANCH_OFFSET; > return ftrace_modify_code(pc, old, new, validate); > } > > [...] > > if (IS_ENABLED(CONFIG_DYNAMIC_FTRACE_WITH_REGS) && > addr == MCOUNT_ADDR) > return ftrace_setup_patchable_entry(pc); > > > This way it clearly show that this is a setup/init corner case. I'll definitely consider this. Thanks for the input, Torsten