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;
Date:   Mon, 7 Nov 2022 14:49:31 +0000
From:   Will Deacon <will@kernel.org>
To:     Jianlin Lv <iecedge@gmail.com>
Cc:     corbet@lwn.net, catalin.marinas@arm.com, rostedt@goodmis.org,
        mingo@redhat.com, naveen.n.rao@linux.ibm.com,
        anil.s.keshavamurthy@intel.com, davem@davemloft.net,
        mhiramat@kernel.org, arnd@arndb.de, zhengzengkai@huawei.com,
        jianlv@ebay.com, linux-kernel@vger.kernel.org,
        linux-doc@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
        mark.rutland@arm.com
Subject: Re: [PATCH] arm64/kprobes: Add support for KPROBES_ON_FTRACE
Message-ID: <20221107144931.GA20793@willie-the-truck>
References: <20220728020250.1699-1-iecedge@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20220728020250.1699-1-iecedge@gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk

[+Mark R]

On Thu, Jul 28, 2022 at 02:02:50AM +0000, Jianlin Lv wrote:
> This is the arm64 version of ftrace-based kprobes to avoid the overhead
> with regular kprobes, by using the ftrace infrastructure.
> 
> Signed-off-by: Jianlin Lv <iecedge@gmail.com>
> ---
>  .../debug/kprobes-on-ftrace/arch-support.txt  |  2 +-
>  arch/arm64/Kconfig                            |  1 +
>  arch/arm64/kernel/probes/Makefile             |  1 +
>  arch/arm64/kernel/probes/kprobes-ftrace.c     | 81 +++++++++++++++++++
>  include/linux/kprobes.h                       |  2 +
>  kernel/kprobes.c                              |  4 +-
>  6 files changed, 88 insertions(+), 3 deletions(-)
>  create mode 100644 arch/arm64/kernel/probes/kprobes-ftrace.c

Sorry for the slow reply on this, but I think this deserved to be split
into two patches: the first one reworking the core check_ftrace_location()
logic to work properly with branch-and-link style architectures, and the
second one adding support for arm64.

I'd also prefer that we don't just punt the whole of check_ftrace_location()
to the arch code using weak symbols. I'd have thought it would be cleaner
for architectures to specify the offset which needs to be applied to the
PC instead.

Having said that, how do architectures such as PowerPC and Risc-V handle
this today without changing the core code?

Will