Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp581755ybl; Fri, 10 Jan 2020 03:29:50 -0800 (PST) X-Google-Smtp-Source: APXvYqxP3Rg6Ddgn0Nl8cGvcDsCA7qGXpRPVh7qkJS62x8cXvVeF8m2pV3wME2MZ1fr3KPenALqZ X-Received: by 2002:a05:6808:a83:: with SMTP id q3mr1923349oij.0.1578655790703; Fri, 10 Jan 2020 03:29:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1578655790; cv=none; d=google.com; s=arc-20160816; b=F6/QzWCPiYlkz6nMq+nJ7dzukVGJl56s/DMJT09OAFVgHd+BUPyEMu7GkANXThDfAc Zpla7LW5oeWWocU2zbVJDrJU0m14uLjmYvIiE1swzC1zwNYUy5Q4uGWd6oGJaIpXnYrS epeVH4g9C7EStDfBF3ijV8C2jzLR3xaHk2UAX2Ryx6wkGRfTYeODAMnOLiHe3NLfHYKa anJSZ7dUHAZ1ZSqmz3RLyYRWhBypPD3yGSrGzr6yE7+/gHG4fq81XaDLvSxVI1zfnHPC XBf7d6v1l9j57bkKcE9Y15QMP0i8o1K3hBJtvAeW2v0ebZoZTaXye2oh3M86VLJx8XCN iHhQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=pa3bniQtp0GwdGg75RMtNYW3PROZHgM1eWBopB+AA0Y=; b=Z5/6I1Cj9HKMFXxuL7uUzVkcmiOHBXAC23BdLPINLeLq/Adj+DIh8D3GCxPRFsF+LB mVZaY2axR2AciOZwgk+dfDQ/C1rZqBHDx2xAwGNSTx7PJ9XWNMHG7vdVpW3LvlwhNHpw wLYobzvlGh4j55BqOKG81DrM1gWSrwAgeiyTghA8vyBGo7b5lOJd1W0uto5xocWkTWv3 UkTeeNbFu70IbFehzgjAftthhu1D8HRxiU56sNloGHXxq1SH2aJ8bxTPhqL2izx+NqEU 9RlxxYTsv7MJ7DGbtVDDTFC0COz3K17+UtUrwYl6sG7OewsluWzFqVvs9ibAmr+qtEXk cL/w== 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 q17si1433867otr.219.2020.01.10.03.29.38; Fri, 10 Jan 2020 03:29:50 -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 S1727752AbgAJL2c (ORCPT + 99 others); Fri, 10 Jan 2020 06:28:32 -0500 Received: from szxga04-in.huawei.com ([45.249.212.190]:9152 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727685AbgAJL2c (ORCPT ); Fri, 10 Jan 2020 06:28:32 -0500 Received: from DGGEMS408-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id 22CB5E1CF0C553E95238; Fri, 10 Jan 2020 19:28:29 +0800 (CST) Received: from [127.0.0.1] (10.133.217.236) by DGGEMS408-HUB.china.huawei.com (10.3.19.208) with Microsoft SMTP Server id 14.3.439.0; Fri, 10 Jan 2020 19:28:18 +0800 Subject: Re: [RFC PATCH] arm64/ftrace: support dynamically allocated trampolines To: Mark Rutland CC: , , , , , , , "chengjian (D)" References: <20200109142736.1122-1-cj.chengjian@huawei.com> <20200109164858.GH3112@lakrids.cambridge.arm.com> From: "chengjian (D)" Message-ID: Date: Fri, 10 Jan 2020 19:28:17 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1 MIME-Version: 1.0 In-Reply-To: <20200109164858.GH3112@lakrids.cambridge.arm.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Originating-IP: [10.133.217.236] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Mark     Thanks for your reply. On 2020/1/10 0:48, Mark Rutland wrote: > On Thu, Jan 09, 2020 at 02:27:36PM +0000, Cheng Jian wrote: > > Just how bad is this, and when/where does it matter? > > How much does this patch improve matters? I will have a test about this. >> Known issues : >> If kaslr is enabled, the address of tramp and ftrace call >> may be far away. Therefore, long jump support is required. >> Here I intend to use the same solution as module relocating, >> Reserve enough space for PLT at the end when allocating, can >> use PLT to complete these long jumps. > This can happen both ways; the callsite can also be too far from the > trampoline to be able to branch to it. Yes, that can happen both ways. > I've had issues with that for other reasons, and I think that we might > be able to use -fpatchable-function-entry=N,M to place a PLT immediately > before each function for that. However, I'm wary of doing so because it > makes it much harder to modify the patch site itself. This sounds good. I have no better idea than this now. At least try it first. > >> >> +GLOBAL(ftrace_common_end) >> ret x9 > This doesn't look right. Surely you want the RET, too? I will fix this error, thanks. > +/* > + * ftrace_caller() or ftrace_regs_caller() trampoline > + * +-----------------------+ > + * ftrace_(regs_)caller => | ...... | > + * ftrace_(regs_)caller_end => | b ftrace_common | => nop > + * +-----------------------+ > + * ftrace_common => | ...... | > + * function_trace_op_ptr => | adrp x2, sym | => nop > + * | ldr x2,[x2,:lo12:sym]| => ldr x2 > + * | ...... | > + * ftrace_common_end => | retq | > Copy-paste from x86? arm64 doesn't have a retq instruction. > >> + * +-----------------------+ >> + * ftrace_opt => | ftrace_opt | >> + * +-----------------------+ > Typo: s/opt/ops/ ? Sorry for these scenes. >> + */ >> +static unsigned long create_trampoline(struct ftrace_ops *ops, unsigned int *tramp_size) >> +{ >> + unsigned long start_offset_caller, end_offset_caller, caller_size; >> + unsigned long start_offset_common, end_offset_common, common_size; >> + unsigned long op_offset, offset, size, ip, npages; >> + void *trampoline; >> + unsigned long *ptr; >> + /* ldr x2,