Received: by 2002:a05:6602:2086:0:0:0:0 with SMTP id a6csp4149265ioa; Tue, 26 Apr 2022 18:50:42 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx+5gDz388n5zvG4cOAyB6ENyMw/9zVSBRXJsmPZmSJLNu/fQ464Vd8wMzJLxBDzdauJzb1 X-Received: by 2002:a17:906:4c93:b0:6f0:2de:f42d with SMTP id q19-20020a1709064c9300b006f002def42dmr24502895eju.648.1651024242116; Tue, 26 Apr 2022 18:50:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1651024242; cv=none; d=google.com; s=arc-20160816; b=D+QegJ9eBfdETGZqz5QOPsQvCQWpssKuT8kNgOvNeh7AzLUwN3agZO3lnIcICHy4xJ 544B5iePpXa8ly696YHGOjnbf8iR+soZx2ty5mTNyF81lS5iLIz+3U3f0TJumvcigRNn kLDKqVD6HttHF1p2nLNf9RaeAIdD5hgQuQVFgr6aQDxeCfgJLRkAsp465p6lRdaV71Vr 4KQJwzOOCeMgpG3ArWEgf2Z8QEIntjbYTzD/uNQ7ViWZdWSaJaPgbFXjdec5yV3AfGz2 qJ9f05ywi4evec13Yz51JHx2hxbzwDub1Mh8St+TFXvdB2RMdYX4jWAGO/+uhB1oOr8f zNtA== 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 :dkim-signature; bh=nj1iVw8Om/xxPBwx6m2cmkDtIdRTXlX1fIYnhe07DAI=; b=BjDg/ChIY8pylgx2TX8PjSbAtm67eQBBdhTbVJJo9cksu870Sy2h/kv9+Dc80gA2Yf RTcgXDY/SCP/ffY1AixuHdbyk4kLAuDxuRPTUsz13kq7CNi1leC5wiO4fetZobXgWzGP XB9gb95m8GzyqmQ/ufpmDiBODPkuWRTbyiG9WkUZ/8pmz4xjgrfGs8VHQzVWV5V3PMEN CcG47UjHem1tKkYFSgg1wSJCLZFU5u4sQ72wG1cCirx/eJ6ntlpx2wHIOB3uRV+oOu4W W6iZ8zVqVwC5E11OZkEDAKv1/d8PGnUAvtO6n1r7hpZCgovgpJLmcCUkBsUeI1VxOKz0 9zpQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=XPm+F8IL; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id c31-20020a509fa2000000b00418c2b5be05si226303edf.231.2022.04.26.18.50.16; Tue, 26 Apr 2022 18:50:42 -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; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=XPm+F8IL; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344001AbiDZJgO (ORCPT + 99 others); Tue, 26 Apr 2022 05:36:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39174 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345977AbiDZJG3 (ORCPT ); Tue, 26 Apr 2022 05:06:29 -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 125A8149285 for ; Tue, 26 Apr 2022 01:47:56 -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 A278F60C43 for ; Tue, 26 Apr 2022 08:47:55 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 349B1C385A4; Tue, 26 Apr 2022 08:47:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1650962875; bh=KGgpr/qE7e8i8/TT4uGx7oI4jKojK9A+0qh5p9W935o=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=XPm+F8ILe2J5PO9S7QNt8NoVYK46NXEXjJXFkTMjtiMqb48KhwwqQ1aC/A5cxsNOm 2oXPAWVHvM+dO335YOYApv0pB7ebxVtqIYIwVrUkjeSw5+kVS9oaJe1izMMt6aRwhm vHHJK4TvopkQXA06q+W29TSiB0KQjd7akaGA8w+iM4AHnqgrgvXUND4K5gTSOFL51D Wzcyng+vvFfCo8QKBzlzvP41NDLiZAXKUut/0TX+CAMVcLo+rtlhJCWabZA1ws/aSO xgl84i4K+H2w5kxKo8W/Og1YvVHGSpIe/1c692FSE4h/yB0H5g0omcxZYWPGKd95ad 2tKtL3y7m3uPw== Date: Tue, 26 Apr 2022 17:47:49 +0900 From: Masami Hiramatsu To: Mark Rutland Cc: Steven Rostedt , 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, Masami Hiramatsu Subject: Re: [RFC PATCH -next v2 3/4] arm64/ftrace: support dynamically allocated trampolines Message-Id: <20220426174749.b5372c5769af7bf901649a05@kernel.org> In-Reply-To: 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> <20220422114541.34d71ad9@gandalf.local.home> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; 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=-9.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A, RCVD_IN_DNSWL_HI,SPF_HELO_NONE,SPF_PASS 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 Hi Mark, On Fri, 22 Apr 2022 18:27:53 +0100 Mark Rutland wrote: > On Fri, Apr 22, 2022 at 11:45:41AM -0400, Steven Rostedt wrote: > > On Fri, 22 Apr 2022 11:12:39 +0100 > > Mark Rutland wrote: > > > > > 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). > > > > Note, the reason for the addition of REGS was a requirement of kprobes. > > Because before ftrace, kprobes would be triggered at the start of a > > function by a breakpoint that would load in all the regs. And for backward > > compatibility, Masami wanted to make sure that kprobes coming from ftrace > > had all the regs just like it had when coming from a breakpoint. Yes. Since this kprobes->ftrace conversion is done by kprobes transparently, user doesn't know their kprobe handler is called from sw break or ftrace. > > > > IIUC, kprobes is the only reason we have the "regs" variant (all other use > > cases could get by with the ARGS version). > > I see. FWIW, we don't have KPROBES_ON_FTRACE on arm64. Right. Since x86 fentry puts the entry on function address, I need such compatibility. But on arm64, ftrace leads some preparation instructions, kprobes can put the sw break on the function address there. And may not need to put the kprobes on it. So it depends on arch. I would like to keep the kprobes available at the function address so that it can trace any registers. (like debugger usage) > Also, the same problems apply to KRETPROBES: the synthetic `pstate` > value is bogus and we don't fill in other bits of the regs (e.g. the PMR > value), so it's not a "real" pt_regs, and things like > interrupts_enabled(regs) won't work correctly. Would you mean the process which kprobes_save/restore_local_irqflag() does? Is the regs->pstate saved correctly in sw break or ftrace? (sorry, I missed the context) > In addition, as > KRETPROBES only hooks function entry/exit and x9-x17 + x19-x28 are > meaningless at those times, no-one's going to care what they contain > anyway. It depends on what bug they are trying to trace. C source level bug will not need such information, but assembly level bug (or compiler level bug) may need such registers. Anyway, this also depends on user. I just won't like limit the usage. > The state we can correctly snapshot (and that would be useful) > is the same as ARGS. > > It'd be nice if KRETPROBES could just use ARGS, but a standard KPROBE > that traps could provide regs (since it actually gets "real" regs, and > within a function the other GPRs could be important). Here, the KRETPROBES means the exit handler, or including entry handler? Since kretprobes uses a standard kprobe to trap the function entry. If you talk about fprobes (ftrace probe interface), it will only use the ftrace. Thus your idea is acceptable for it (because fprobe is different from kprobes *). * Of course we have to talk with BPF people so that they will only access ARGS from BPF program on fprobes. Thank you, -- Masami Hiramatsu