Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752838AbbGFOmY (ORCPT ); Mon, 6 Jul 2015 10:42:24 -0400 Received: from mx1.redhat.com ([209.132.183.28]:36996 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752568AbbGFOmF (ORCPT ); Mon, 6 Jul 2015 10:42:05 -0400 Subject: Re: [PATCH 1/2] arm64: Blacklist non-kprobe-able symbols To: Masami Hiramatsu , Will Deacon , Pratyush Anand References: <9994841a0b0a8194a6dcc1b6af148ba358488c62.1436158027.git.panand@redhat.com> <20150706090323.GB30342@arm.com> <559A688D.1040501@hitachi.com> Cc: "linux-arm-kernel@lists.infradead.org" , "linux@arm.linux.org.uk" , Catalin Marinas , "linux-kernel@vger.kernel.org" , "dave.long@linaro.org" , "steve.capper@linaro.org" From: William Cohen Message-ID: <559A93BB.7090007@redhat.com> Date: Mon, 6 Jul 2015 10:42:03 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <559A688D.1040501@hitachi.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1924 Lines: 35 On 07/06/2015 07:37 AM, Masami Hiramatsu wrote: > On 2015/07/06 18:03, Will Deacon wrote: >> On Mon, Jul 06, 2015 at 06:03:21AM +0100, Pratyush Anand wrote: >>> Add all function symbols which are called from do_debug_exception under >>> NOKPROBE_SYMBOL, as they can not kprobed. >> >> It's a shame this has to be so manual, but I suppose it's done on a >> best-effort basis to catch broken probe placement. > > Ah, yes. You can use kprobe-tracer in ftrace by feeding all symbols to > them and enabling it (and pray). Yes, this approach isn't guaranteed to find problem functions. There could be problems hidden on conditional paths that are rarely called. This was observed with the aarch64 kretprobe trampoline handler. Most times it wouldn't call kfree and everything would run fine. However, sometimes the kfree which was instrumented for a systemtap test would get called from inside the trampoline handler and trigger a recursive exception. This is why aarch64 tramopline was rewritten avoid using kprobe. Is there some tool that can generate a static call graph of the kernel? Maybe use the output of that to get more complete list of which functions should be off limits for kprobes. One complication is that some tools might not analyze functions written in assembly and miss some possible function calls. -Will Cohen > > >> If we miss a function and somebody probes it, do we just get stuck in a >> recursive exception, or could we print something suggesting that a symbol >> be annotated as NOKPROBE? > > For some cases we can detect recursion, but usually, it may reset > itself or infinite recursion loop before detecting it. :( > > Thank you, > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/