Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp6230418iob; Tue, 10 May 2022 13:25:39 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz5fF0BM17xBOpXsnAYOLrC9neZbiixzJdOao+fnt0g+/BKPoCa6UJopKDWUXYHgjQgDqP1 X-Received: by 2002:a05:6870:8985:b0:da:b3f:3253 with SMTP id f5-20020a056870898500b000da0b3f3253mr1051757oaq.259.1652214339569; Tue, 10 May 2022 13:25:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1652214339; cv=none; d=google.com; s=arc-20160816; b=DUBJkxKggFNs1KfcFWn4g70xCWd6Py04eOAqDWYUzx6tfdD/5EXQ4ZU5jVCo7lX2ea c/VHjtkr945Cj0WAXNZyGNlXz6Zu2F/7sgM4gLyWSGnq6ocxWXZKJh3LK2WRONS5FEo9 tVgRaJDGZH/Sw767TO9HzioSGOMrAuBZSEi7hK3ETLBKZSSyba//R9LQKLMlzXjQrNaU HDAOuXwWDutoZjeC4524OYjjI1b+jNxcYt1rS0XWsCCBGr2YeLJsbeSeDczxmstn/Jai urYzUBYe1037wYjEHj5LE7mRPDA/2XszDeYErA93VCV1Hcda67KmLNbih4JyAqnJJAgx yscQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=XFowRvOj/szoSPvGx+A3LwyLyKAr20NDQf4pH/ZYN1Y=; b=fYrGgPNFJbGjV8SQHriVJtcrkNOw6Dn21omD2Y48jwxSqO+i7p0UEKsIQM7RPUyPEi D0ZMl+78YG4HLtBaTxRpBJTfursaUFUGPLDk/rrBWS7gHrSTSdAZgx4e/v4apLOSiJXj O5G0b5UW2Ck/AKf/cvFyYHUphukw7WotwUTZnk0mJV1gWNEy7UUcIaFoB+ezJFVfcsBW V7lBoMDUeN8nqtLCgCxrhWBCZNqrsXC1C79clWHdrX4DvR3IKknDMGAgO+1spyivAXgL m425noTd1a5JuOKWPQLhyxamZ6WyhLX5/VDFFUhE7uO7ItK7HsLck60hqWjVvDAsciXT pXhQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id bc30-20020a056820169e00b003244bc5df23si388603oob.31.2022.05.10.13.25.24; Tue, 10 May 2022 13:25:39 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345412AbiEJPMG (ORCPT + 99 others); Tue, 10 May 2022 11:12:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51732 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346052AbiEJPLr (ORCPT ); Tue, 10 May 2022 11:11:47 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A138724EA05 for ; Tue, 10 May 2022 07:44:50 -0700 (PDT) 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 dfw.source.kernel.org (Postfix) with ESMTPS id EA458617D9 for ; Tue, 10 May 2022 14:44:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0DF37C385C2; Tue, 10 May 2022 14:44:47 +0000 (UTC) Date: Tue, 10 May 2022 10:44:46 -0400 From: Steven Rostedt To: Masami Hiramatsu Cc: Mark Rutland , 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, Jiri Olsa Subject: Re: [RFC PATCH -next v2 3/4] arm64/ftrace: support dynamically allocated trampolines Message-ID: <20220510104446.6d23b596@gandalf.local.home> In-Reply-To: <20220510181012.d5cba23a2547f14d14f016b9@kernel.org> References: <20220421100639.03c0d123@gandalf.local.home> <20220421114201.21228eeb@gandalf.local.home> <20220421130648.56b21951@gandalf.local.home> <20220422114541.34d71ad9@gandalf.local.home> <20220426174749.b5372c5769af7bf901649a05@kernel.org> <20220505121538.04773ac98e2a8ba17f675d39@kernel.org> <20220509142203.6c4f2913@gandalf.local.home> <20220510181012.d5cba23a2547f14d14f016b9@kernel.org> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.7 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_HI,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 10 May 2022 18:10:12 +0900 Masami Hiramatsu wrote: > > > > This was suggested by both Peter Zijlstra and Thomas Gleixner when I > > introduced FTRACE_WITH_ARGS, where all functions can now get the arguments > > from fregs, but not the full pt_regs. > > Hmm, I thought the ftrace_get_regs() is the all-or-nothing interface, or > is there any way to get the arguments from fregs? Not yet generically. But that can easily be added. If you look at x86 live patching, since it is arch specific, it just took the regs parameter directly, knowing that the args were already set up. That is, ftrace_regs is just a wrapper around pt_regs with just the regs for the arguments and stack initialized. If you get regs from ftrace_get_regs(fregs) it will return NULL if it wasn't full set of regs. But we can add generic functions to get the parameters. That is, we can create a ftrace_get_kernel_argument() function that takes fregs instead of pt_regs, and produce the same thing as regs_get_kernel_argument(). x86 live kernel patching has this: arch/x86/include/asm/ftrace.h: #define ftrace_instruction_pointer_set(fregs, _ip) \ do { (fregs)->regs.ip = (_ip); } while (0) arch/x86/include/asm/livepatch.h: static inline void klp_arch_set_pc(struct ftrace_regs *fregs, unsigned long ip) { ftrace_instruction_pointer_set(fregs, ip); } Where fregs is not a full set of regs. > > > If a ftrace_ops has the REGS flag set > > (using ftrace_regs_caller), the ftrace_get_regs(fregs) will return the > > pt_regs, or it will return NULL if ftrace_regs_caller was not used. > > > > This way the same parameter can provide full pt_regs or a subset, and have > > an generic interface to tell the difference. > > If it can provide a partial (subset of) pt_regs, that could be good for me > too, since at least kprobe-events on ftrace can check the traced register > is in the subset or not and reject it if it doesn't saved. That's exactly the use case for ftrace_regs. -- Steve