From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 76139C433EF for ; Fri, 22 Apr 2022 10:13:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=C8qZhYhTeJ1fERHpR500cPHvqXt+afIfs2QHs1Humc4=; b=Qmsz9r9ncazu8s ZemNU8uoAw3E0aNDRQ5MIqxAxu5j/IquBsGmJh2LrEfpanbtF4XCfXj14GjtdfLdLa/BBm+o186u0 BvKBdR4BuQGX49+FBf2VM6cCsg5H/DGRpR/ZEzxzQepQM2C6z65ThlyYf9rnieY/yDURvFL82kOsn NQtoJ/XZc5pO29EpqtvrNQwTCykpNNGS/DTVv2wC3pMEcGfbrjzSgkSsXi/oT4cjO7L/awRcMeOq7 SLDRGMfkZKenZauwF2S3OVV3jF/XQRv+louFoEMziGPRtT8TUAKN5DqVRq46vm0wVfYc1ndFhpDwt P5b+54MxYVQisXnEAgnw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nhqHV-00HXda-Df; Fri, 22 Apr 2022 10:12:53 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nhqHR-00HXc5-RQ for linux-arm-kernel@lists.infradead.org; Fri, 22 Apr 2022 10:12:51 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 4CAD31576; Fri, 22 Apr 2022 03:12:46 -0700 (PDT) Received: from FVFF77S0Q05N (unknown [10.57.74.110]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 7D0D33F766; Fri, 22 Apr 2022 03:12:44 -0700 (PDT) Date: Fri, 22 Apr 2022 11:12:39 +0100 From: Mark Rutland To: Steven Rostedt Cc: Wang ShaoBo , cj.chengjian@huawei.com, huawei.libin@huawei.com, xiexiuqi@huawei.com, liwei391@huawei.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, catalin.marinas@arm.com, will@kernel.org, zengshun.wu@outlook.com Subject: Re: [RFC PATCH -next v2 3/4] arm64/ftrace: support dynamically allocated trampolines Message-ID: References: <20220316100132.244849-1-bobo.shaobowang@huawei.com> <20220316100132.244849-4-bobo.shaobowang@huawei.com> <20220421100639.03c0d123@gandalf.local.home> <20220421114201.21228eeb@gandalf.local.home> <20220421130648.56b21951@gandalf.local.home> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20220421130648.56b21951@gandalf.local.home> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220422_031249_978706_7DE879B9 X-CRM114-Status: GOOD ( 18.86 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Apr 21, 2022 at 01:06:48PM -0400, Steven Rostedt wrote: > On Thu, 21 Apr 2022 17:27:40 +0100 > Mark Rutland wrote: > > > We can initialize the ops pointer to a default ops that does the whole > > __do_for_each_ftrace_ops() dance. > > OK, I think I understand now. What you are doing is instead of creating a > trampoline that has all the information in the trampoline, you add nops to > all the functions where you can place the information in the nops (before > the function), and then have the trampoline just read that information to > find the ops pointer as well as the function to call. Yup! > I guess you could have two trampolines as well. One that always calls the > list loop, and one that calls the data stored in front of the function that > was just called the trampoline. As it is always safe to call the loop > function, you could have the call call that trampoline first, set up the > specific data before the function, then call the trampoline that will read > it. And same thing for tear down. Having separate trampolines is possible, but there are some complications, and we might end up with an explosion of trampolines (and associated module PLTs) due to needing BTI/!BTI and REGs/!REGS variants, so if it's possible to have a default ops that handled the list case, that'd be my preference to keep that simple and manageable. As an aside, I'd also love to remove the REGS/!REGs distinction, and always save a minimum amount of state (like ARGS, but never saving a full pt_regs), since on arm64 the extra state stored for the REGS case isn't useful (and we can't reliably capture all of the pt_regs state anyway, so bits of it are made up or not filled in). Thanks, Mark. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel