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 2D3B1EE57EE for ; Wed, 11 Sep 2024 23:55:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type: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=zzT5tRY4/lhF2xscFKT7AnN+ywzvk8Dfs4A+Oc8aqrs=; b=EaXl1HEu+WdYi+ye3f1m23MmwX lVNqpUsmVa+0bKI1Y4Ks3t/eUek9WuYIyisUCY5gsMqFecBLgmWE6msPUqQPx6UjQqRePNf2eC5MV 05OLHSZ6wX6cYe6ePb0s9uyQx+mobHSADp6zHceJ23mRTgLrvCGGkx0b8onprF2geLAHi5T+ffJwm pO/tc0FU46fl1t7Y9/2uGRovrBIBLAI5fB9Sx7VgWPr2HmOssB2UhSfyeVPbVOr/pwfRIN+WHDyq+ P3i5A4eyY8w21M7HyCchkgDcIo2TwJJL9ecw/OfRLx1+dmiColeoNMLrVtyR2H3e8HtUjjvGodH4U YtRKTL5Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1soXAp-0000000BNcB-0FaY; Wed, 11 Sep 2024 23:54:59 +0000 Received: from nyc.source.kernel.org ([147.75.193.91]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1soX9l-0000000BNYI-2lHB for linux-arm-kernel@lists.infradead.org; Wed, 11 Sep 2024 23:53:54 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id E183BA41410; Wed, 11 Sep 2024 23:53:44 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BE15EC4CEC0; Wed, 11 Sep 2024 23:53:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1726098832; bh=ewXwRnugXYXsCY1PEPRe8FMZ36d1aPzdmQ+2IRD3E9Y=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=kaZCSVQO0u6e+HbGwoP4zYmk/jYQzfn5J732qvCqqSPW8stpMt8w5hrBnXi7Dz3G/ NvbDtN5fKUKfkJCUd74GRfgrFSnZH6L03ekj8Jh4vF//7vX/vxDni+iZpwfVbG912M ID1CzANATF3wV+55XPl03UjM6ErAAbr580xRA9QjF22hFoaoIFt0mxE4CfD0B9+HDv HZLk6XMrUW+LQaYkOD4L8m79USeoTSJTXj9t0M7SFO1wSa3icN4Kp6u8vUabGBcBJL 8cpZhcywe6DIyWmmIIXKGy2kW54GVy+s6n61Sv0bThZA7smsZdiNPpAfdNorxykaIV 741p9enWKkYXw== Date: Thu, 12 Sep 2024 08:53:46 +0900 From: Masami Hiramatsu (Google) To: Andrii Nakryiko Cc: Mark Rutland , Jiri Olsa , Steven Rostedt , bpf , Linux trace kernel , adubey@linux.ibm.com, "Naveen N. Rao" , KP Singh , linux-arm-kernel , Will Deacon , Alexei Starovoitov , Catalin Marinas , Florent Revest , Puranjay Mohan Subject: Re: Unsupported CONFIG_FPROBE and CONFIG_RETHOOK on ARM64 Message-Id: <20240912085346.154b18ca686c7c4595e93c9a@kernel.org> In-Reply-To: References: <20240911091343.77c60bc2e5d96cbfd8787c19@kernel.org> <20240912001848.d9629a1579ea3ef6531a9a0b@kernel.org> X-Mailer: Sylpheed 3.7.0 (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-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240911_165353_804231_C23C6157 X-CRM114-Status: GOOD ( 17.77 ) 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, 11 Sep 2024 13:18:12 -0700 Andrii Nakryiko wrote: > > > So while I get the desire to have a clean and nice > > > end goal, and that it might take a bit longer to get everything right. > > > But, maybe, landing a stop-gap solution meanwhile (especially as > > > isolated and thus easily backportable as the patch [0] you referenced) > > > is an OK path forward? > > > > I had not realized that the PSTATE register was not saved correctly > > at that point. This is one reason why I decided to move in the > > current fprobe-on-fgraph direction. > > Sure, but you said yourself, the same problem exists with current > kretprobe implementation, so this won't regress anything. And yes, > your fprobe-on-fgraph series is supposed to fix this for good, which > is great, but that's a separate topic. It does not regress kretprobe, but introduces the same problem to fprobe. And since fprobe-on-fgraph was boosted by this problem, I think that is not a separate topic. Thank you, -- Masami Hiramatsu (Google)