From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3971 invoked by alias); 24 Mar 2014 19:37:06 -0000 Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org Received: (qmail 3959 invoked by uid 89); 24 Mar 2014 19:37:05 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: cdptpa-oedge-vip.email.rr.com Received: from cdptpa-outbound-snat.email.rr.com (HELO cdptpa-oedge-vip.email.rr.com) (107.14.166.232) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 24 Mar 2014 19:37:05 +0000 Received: from [67.255.60.225] ([67.255.60.225:53236] helo=gandalf.local.home) by cdptpa-oedge01 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id A6/3A-17209-E5980335; Mon, 24 Mar 2014 19:37:03 +0000 Date: Mon, 24 Mar 2014 19:37:00 -0000 From: Steven Rostedt To: Masami Hiramatsu Cc: linux-kernel@vger.kernel.org, Ingo Molnar , Andi Kleen , Ananth N Mavinakayanahalli , Sandeepa Prabhu , Frederic Weisbecker , x86@kernel.org, fche@redhat.com, mingo@redhat.com, systemtap@sourceware.org, "H. Peter Anvin" , Thomas Gleixner , "David S. Miller" Subject: Re: [PATCH -tip v8 11/26] kprobes: Allow probe on some kprobe functions Message-ID: <20140324153701.18857126@gandalf.local.home> In-Reply-To: <20140305120000.22766.77897.stgit@ltc230.yrl.intra.hitachi.co.jp> References: <20140305115843.22766.8355.stgit@ltc230.yrl.intra.hitachi.co.jp> <20140305120000.22766.77897.stgit@ltc230.yrl.intra.hitachi.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RR-Connecting-IP: 107.14.168.118:25 X-SW-Source: 2014-q1/txt/msg00344.txt.bz2 On Wed, 05 Mar 2014 21:00:00 +0900 Masami Hiramatsu wrote: > There is no need to prohibit probing on the functions > used for preparation, registeration, optimization, > controll etc. Those are safely probed because those are > not invoked from breakpoint/fault/debug handlers, > there is no chance to cause recursive exceptions. > > Following functions are now removed from the kprobes blacklist. > add_new_kprobe > aggr_kprobe_disabled > alloc_aggr_kprobe > alloc_aggr_kprobe > arm_all_kprobes > __arm_kprobe > arm_kprobe > arm_kprobe_ftrace > check_kprobe_address_safe > collect_garbage_slots > collect_garbage_slots > collect_one_slot > debugfs_kprobe_init > __disable_kprobe > disable_kprobe > disarm_all_kprobes > __disarm_kprobe > disarm_kprobe > disarm_kprobe_ftrace > do_free_cleaned_kprobes > do_optimize_kprobes > do_unoptimize_kprobes > enable_kprobe > force_unoptimize_kprobe > free_aggr_kprobe > free_aggr_kprobe > __free_insn_slot > __get_insn_slot > get_optimized_kprobe > __get_valid_kprobe > init_aggr_kprobe > init_aggr_kprobe > in_nokprobe_functions > kick_kprobe_optimizer > kill_kprobe > kill_optimized_kprobe > kprobe_addr > kprobe_optimizer > kprobe_queued > kprobe_seq_next > kprobe_seq_start > kprobe_seq_stop > kprobes_module_callback > kprobes_open > optimize_all_kprobes > optimize_kprobe > prepare_kprobe > prepare_optimized_kprobe > register_aggr_kprobe > register_jprobe > register_jprobes > register_kprobe > register_kprobes > register_kretprobe > register_kretprobe > register_kretprobes > register_kretprobes > report_probe > show_kprobe_addr > try_to_optimize_kprobe > unoptimize_all_kprobes > unoptimize_kprobe > unregister_jprobe > unregister_jprobes > unregister_kprobe > __unregister_kprobe_bottom > unregister_kprobes > __unregister_kprobe_top > unregister_kretprobe > unregister_kretprobe > unregister_kretprobes > unregister_kretprobes > wait_for_kprobe_optimizer > Did you test these like you did with the previous patch? What about the middle of these functions? -- Steve