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 X-Spam-Level: X-Spam-Status: No, score=-4.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6BDD2C55178 for ; Thu, 29 Oct 2020 08:07:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 12C112076E for ; Thu, 29 Oct 2020 08:07:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1603958867; bh=kpWNJPWGD4JFwLM+mHUyzzxC6LBl3TEm0/BDqlS76+w=; h=Date:From:To:Cc:Subject:In-Reply-To:References:List-ID:From; b=qq+l5Y9Csbyi1MaPxks02g4pH970uNJIm/BQmrWCPg4+mzfeaBpRthGhXzI+r6Wpg 70vZjVMW+4E8XaQxdoWV5g5dyVxmSkTKkCghUgosa5IXRPYb0Vjw64jal/s2/Tx6Zo ChrmUyJvlXCwiWPKg9jlDNk+QAutFjZ585Y72yF0= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726859AbgJ2IHp (ORCPT ); Thu, 29 Oct 2020 04:07:45 -0400 Received: from mail.kernel.org ([198.145.29.99]:34852 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726714AbgJ2IHk (ORCPT ); Thu, 29 Oct 2020 04:07:40 -0400 Received: from devnote2 (NE2965lan1.rev.em-net.ne.jp [210.141.244.193]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 2AC522071A; Thu, 29 Oct 2020 08:07:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1603958860; bh=kpWNJPWGD4JFwLM+mHUyzzxC6LBl3TEm0/BDqlS76+w=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=p5j/vgBuQezI6kR9EU1fwI5RM0bNnX6e2eSjaPejpXXKukozYtdR1oYABLFUxNbtI CZnvYEO7FvMZi0KhP7nnKClDG+0QQ5CqIC90UWrM7jnRJVgtMBVNz77OV3proh2Kwo 5y/F5YAlACNAemiizQ//E4r1aRGnkNYM2XQLFMhE= Date: Thu, 29 Oct 2020 17:07:36 +0900 From: Masami Hiramatsu To: Steven Rostedt Cc: linux-kernel@vger.kernel.org, Masami Hiramatsu , Andrew Morton , Jiri Kosina , Thomas Gleixner , Peter Zijlstra , Ingo Molnar , Alexei Starovoitov , Jiri Olsa , Josh Poimboeuf Subject: Re: [RFC][PATCH 1/2 v2] ftrace/x86: Allow for arguments to be passed in to REGS by default Message-Id: <20201029170736.938ded569b436c858ebc2555@kernel.org> In-Reply-To: <20201028112916.50bcbc69@oasis.local.home> References: <20201028131542.963014814@goodmis.org> <20201028131909.738751907@goodmis.org> <20201028102502.28095c95@oasis.local.home> <20201028112916.50bcbc69@oasis.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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 28 Oct 2020 11:29:16 -0400 Steven Rostedt wrote: > Hi Masami, > > Talking with Peter and Thomas on IRC, where they really don't like > passing a partial pt_regs around, got me thinking of redoing the REGS > parameter of ftrace. Kprobes is the only user that requires the full > registers being saved, and that's only because some kprobe user might > want them. Yes, kprobes can be used for debugging use case. I think we can skip coller-saved registers (because ftrace is embedded by compiler and it may save such registers correctly), but we still need a pt_regs on memory to access it. > > On Wed, 28 Oct 2020 10:25:02 -0400 > Steven Rostedt wrote: > > > > typedef void (*ftrace_func_t)(unsigned long ip, unsigned long parent_ip, > > struct ftrace_ops *op, struct pt_regs *regs); > > > > > Most registers of pt_regs at a start of a function is rather useless. > What if we got rid of FL_SAVE_REGS all together and had a "ftrace_regs" > structure passed in that would have only access to all the argument > registers, the stack pointer and the instruction pointer? Yeah, that's OK to me. If someone wants to investigate suspicious compiler bug, they should not put a kprobe on the fentry call site. (in most cases symbol+5 will put a breakpoint right after fentry nop) > Then kprobes could just create its own pt_regs, fill in all the data > from ftrace_regs and then fill the rest with zeros or possibly whatever > the values currently are (does it really matter what those registers > are?), including flags. That sounds good to me. > > Not only would this simplify the code, it would probably allow moving > more of the kprobe code from the arch specific to the generic code, and > remove a lot of duplication. Ah, right. > > This would also help speed up the processing of live kernel patching. > > And best of all, it would give everything access to the arguments of a > function and a stack pointer with out (ab)using pt_regs. > > Do you think this would be feasible? Yes, I agreed. Thank you, > > -- Steve -- Masami Hiramatsu