From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15898 invoked by alias); 11 Dec 2013 02:12:42 -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 15884 invoked by uid 89); 11 Dec 2013 02:12:41 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 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; Wed, 11 Dec 2013 02:12:40 +0000 Received: from mlsv1.hitachi.co.jp (unknown [133.144.234.166]) by mail4.hitachi.co.jp (Postfix) with ESMTP id 8CEEB33CCC; Wed, 11 Dec 2013 11:12:32 +0900 (JST) Received: from mfilter06.hitachi.co.jp by mlsv1.hitachi.co.jp (8.13.1/8.13.1) id rBB2CWkX026462; Wed, 11 Dec 2013 11:12:32 +0900 Received: from vshuts02.hitachi.co.jp (vshuts02.hitachi.co.jp [10.201.6.84]) by mfilter06.hitachi.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id rBB2CTQg002759; Wed, 11 Dec 2013 11:12:31 +0900 Received: from gxml20a.ad.clb.hitachi.co.jp (unknown [158.213.157.160]) by vshuts02.hitachi.co.jp (Postfix) with ESMTP id 89C88490068; Wed, 11 Dec 2013 11:12:31 +0900 (JST) Received: from [10.198.194.77] by gxml20a.ad.clb.hitachi.co.jp (Switch-3.1.10/Switch-3.1.9) id 5BB20CUS900004C28; Wed, 11 Dec 2013 11:12:31 +0900 Message-ID: <52A7CA0A.9060009@hitachi.com> Date: Wed, 11 Dec 2013 02:12: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: Ingo Molnar Cc: Ananth N Mavinakayanahalli , Sandeepa Prabhu , 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> <20131205102127.GA19923@gmail.com> <52A137B6.6030307@hitachi.com> <20131210152811.GA1195@gmail.com> In-Reply-To: <20131210152811.GA1195@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2013-q4/txt/msg00385.txt.bz2 (2013/12/11 0:28), Ingo Molnar wrote: > > * Masami Hiramatsu wrote: > >> (2013/12/05 19:21), Ingo Molnar wrote: >>> >>> * Masami Hiramatsu wrote: >>> >>>>> So we need both a maintainable and a sane/safe solution, and I'd >>>>> like to apply the whole thing at once and be at ease that the >>>>> solution is round. We should have done this years ago. >>>> >>>> For the safeness of kprobes, I have an idea; introduce a whitelist >>>> for dynamic events. AFAICS, the biggest unstable issue of kprobes >>>> comes from putting *many* probes on the functions called from >>>> tracers. >>> >>> If the number of 'noprobe' annotations is expected to explode then >>> maybe another approach should be considered. >> >> No, since this is a "quantitative" issue, the annotation helps us. Sorry for confusion, it should be "the annotation helps us to solves only for qualitative issue". It's my miss... >>> For example in perf we detect recursion. Could kprobes do that and >>> detect hitting a probe while running kprobes code, and ignore it [do >>> an early return]? >> >> Yes, the kprobe itself already has recursion detector and it rejects >> calling handler. > > So why are annotations needed at all? What can happen if an annotation > is missing and a piece of code is probed which is also used by the > kprobes code internally - do we crash, lock up, misbehave or handle it > safely? The kprobe has recursion detector, but it is detected in the kprobe exception(int3) handler, this means that if we put a probe before detecting the recursion, we'll do an infinite recursion. And also, even if we can detect the recursion, we can't stop the kernel, we need to skip the probe. This means that we need to recover to the main execution path by doing single step. As you may know, since the single stepping involves the debug exception, we have to avoid proving on that path too. Or we'll have an infinite recursion again. This is the basic reason why the __kprobes annotation is introduced. Thank you, -- Masami HIRAMATSU IT Management Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu.pt@hitachi.com