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 63737C61DA4 for ; Wed, 15 Mar 2023 23:52:53 +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:MIME-Version:References:In-Reply-To: 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=UpLFK++2TlLurma0/Ov/IQuwttj2b5O9iihPmylUmtk=; b=WRQtDZFEoRo6Rv tM9jfQU/1kAbIdPXmLkyV815CI1kT3ps6JKebHBhpFvfqY9diQ4oUdULa7YOncGKWDQ32pwzpyiId j36muK1bsfwBh3mvPaPHHnfLVArpRBUY/EGvMqgfGla6Jtu2cVwsFtIF4VkZD5Wp1ARi6ByXoU07J 3NeInLxNhZ8hNVUtjqrex1GUScLwfV7uVaKz8WxhqJbn47XxAb4dEey6dzskp6rQl8WkWER9iLHWh w1ZWrjkzYV2+94Wy1vv2Mz6X+VCYwazGpsrhTqfG/TkT7HHvxLJLCsO3hezCN56BQ6QChP3q+tqkb vAcnqao1hpvL5O5JDwdw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1pcauL-00ElTn-0B; Wed, 15 Mar 2023 23:51:49 +0000 Received: from ams.source.kernel.org ([2604:1380:4601:e00::1]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1pcauG-00ElTF-0x for linux-arm-kernel@lists.infradead.org; Wed, 15 Mar 2023 23:51:46 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 868CFB81E91; Wed, 15 Mar 2023 23:51:42 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 632F8C433D2; Wed, 15 Mar 2023 23:51:39 +0000 (UTC) Date: Wed, 15 Mar 2023 19:51:36 -0400 From: Steven Rostedt To: Florent Revest Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, catalin.marinas@arm.com, will@kernel.org, mhiramat@kernel.org, mark.rutland@arm.com, ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org, kpsingh@kernel.org, jolsa@kernel.org, xukuohai@huaweicloud.com, lihuafei1@huawei.com, Xu Kuohai Subject: Re: [PATCH v2 06/10] ftrace: selftest: remove broken trace_direct_tramp Message-ID: <20230315195136.2996b1dd@gandalf.local.home> In-Reply-To: <20230207182135.2671106-7-revest@chromium.org> References: <20230207182135.2671106-1-revest@chromium.org> <20230207182135.2671106-7-revest@chromium.org> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230315_165144_653462_4B264271 X-CRM114-Status: GOOD ( 28.63 ) 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 Tue, 7 Feb 2023 19:21:31 +0100 Florent Revest wrote: > From: Mark Rutland > > The ftrace selftest code has a trace_direct_tramp() function which it > uses as a direct call trampoline. This happens to work on x86, since the > direct call's return address is in the usual place, and can be returned > to via a RET, but in general the calling convention for direct calls is > different from regular function calls, and requires a trampoline written > in assembly. > > On s390, regular function calls place the return address in %r14, and an > ftrace patch-site in an instrumented function places the trampoline's > return address (which is within the instrumented function) in %r0, > preserving the original %r14 value in-place. As a regular C function > will return to the address in %r14, using a C function as the trampoline > results in the trampoline returning to the caller of the instrumented > function, skipping the body of the instrumented function. > > Note that the s390 issue is not detcted by the ftrace selftest code, as > the instrumented function is trivial, and returning back into the caller > happens to be equivalent. > > On arm64, regular function calls place the return address in x30, and > an ftrace patch-site in an instrumented function saves this into r9 > and places the trampoline's return address (within the instrumented > function) in x30. A regular C function will return to the address in > x30, but will not restore x9 into x30. Consequently, using a C function > as the trampoline results in returning to the trampoline's return > address having corrupted x30, such that when the instrumented function > returns, it will return back into itself. > > To avoid future issues in this area, remove the trace_direct_tramp() > function, and require that each architecture with direct calls provides > a stub trampoline, named ftrace_stub_direct_tramp. This can be written > to handle the architecture's trampoline calling convention, and in > future could be used elsewhere (e.g. in the ftrace ops sample, to > measure the overhead of direct calls), so we may as well always build it > in. > > Signed-off-by: Mark Rutland > Cc: Li Huafei > Cc: Xu Kuohai > Cc: Steven Rostedt (Google) > Cc: Florent Revest > Signed-off-by: Florent Revest Care to respin with my update requests? I can take up to this patch and base it directly on v6.3-rc3 when it comes out. I'm expecting that to have the fixes in other code that is breaking my tests. Then I'll push it out after it passes all my tests, and you can take it and add the arm64 specific bits on top. I'm currently running these patches as is on my tests to see if they fail (with a patched kernel for the other code that's breaking my tests). Does that sound OK? -- Steve _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel