From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12998 invoked by alias); 6 Dec 2013 23:26:11 -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 12986 invoked by uid 89); 6 Dec 2013 23:26:11 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail4.hitachi.co.jp Received: from Unknown (HELO mail4.hitachi.co.jp) (133.145.228.5) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 06 Dec 2013 23:26:10 +0000 Received: from mlsv1.hitachi.co.jp (unknown [133.144.234.166]) by mail4.hitachi.co.jp (Postfix) with ESMTP id AA5FD33CC2; Sat, 7 Dec 2013 08:26:02 +0900 (JST) Received: from mfilter05.hitachi.co.jp by mlsv1.hitachi.co.jp (8.13.1/8.13.1) id rB6NQ2Ap014283; Sat, 7 Dec 2013 08:26:02 +0900 Received: from vshuts04.hitachi.co.jp (vshuts04.hitachi.co.jp [10.201.6.86]) by mfilter05.hitachi.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id rB6NQ1gK012103; Sat, 7 Dec 2013 08:26:02 +0900 Received: from gxml20a.ad.clb.hitachi.co.jp (unknown [158.213.157.160]) by vshuts04.hitachi.co.jp (Postfix) with ESMTP id 09191140043; Sat, 7 Dec 2013 08:26:01 +0900 (JST) Received: from [10.198.194.91] by gxml20a.ad.clb.hitachi.co.jp (Switch-3.1.10/Switch-3.1.9) id 5B6N0Q0NI00009898; Sat, 07 Dec 2013 08:26:00 +0900 Message-ID: <52A25CF0.9030706@hitachi.com> Date: Fri, 06 Dec 2013 23:26:00 -0000 From: Masami Hiramatsu User-Agent: Mozilla/5.0 (Windows NT 5.2; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Sandeepa Prabhu Cc: Ingo Molnar , Ananth N Mavinakayanahalli , x86@kernel.org, lkml , "Steven Rostedt (Red Hat)" , systemtap@sourceware.org, "David S. Miller" Subject: Re: [PATCH -tip v4 0/6] kprobes: introduce NOKPROBE_SYMBOL() and fixes crash bugs References: <20131204012841.22118.82992.stgit@kbuild-fedora.novalocal> <20131204084551.GA31772@gmail.com> <529FBA71.6070107@hitachi.com> <52A16D49.9050105@hitachi.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2013-q4/txt/msg00351.txt.bz2 (2013/12/06 15:54), Sandeepa Prabhu wrote: >>> I am not sure if this question is related, uprobes or ftrace code does >>> not define __kprobes, so is it safe to place kprobe on uprobes or >>> ftrace code? >> >> Yes, it is "safe" in qualitative meaning. But for ftrace code, it could >> give a performance impact by miss-hitting. Since uprobe is independent >> from kprobe, it should work. >> >>> Is it expected from arch code to support such cases? >> >> Yes, the arch dependent implementation is the key. If it shares some >> code which can be called from miss-hit path, it should be blacklisted. > well, isn't the blacklist only for those routines that can not be > handled or may crash kernel, like the code sections called from > exception kprobes exception handlers etc? Yes, that's why the blacklist is needed. > suppose if the probe on routine can miss-hit (probes re-cursing) but > can be handled, it's only a quantitative issue (i.e. performance > impact) so it should be *user's* problem right? I mean, as you said > earlier about having white-list or a performance gatekeeper > (systemtap), one can avoid such cases by white list or removing > miss-hit probes dynamically. But a blacklisting a symbol means > placing a probe on that *can not be handled* and can crash the system, > is it correct? Yes, exactly that is what I meant. :) The blacklist is only for avoiding such fundamental issue, therefore, it strongly depends on the architecture code. Thank you, -- Masami HIRAMATSU IT Management Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu.pt@hitachi.com