From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932656AbaEGLTM (ORCPT ); Wed, 7 May 2014 07:19:12 -0400 Received: from mail7.hitachi.co.jp ([133.145.228.42]:52579 "EHLO mail7.hitachi.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932352AbaEGLTL (ORCPT ); Wed, 7 May 2014 07:19:11 -0400 X-Greylist: delayed 93206 seconds by postgrey-1.27 at vger.kernel.org; Wed, 07 May 2014 07:19:10 EDT Message-ID: <536A16A6.5040709@hitachi.com> Date: Wed, 07 May 2014 20:19:02 +0900 From: Masami Hiramatsu Organization: Hitachi, Ltd., Japan User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Tony Luck , Benjamin Herrenschmidt , Paul Mackerras Cc: Ingo Molnar , Linus Torvalds , Rusty Russell , rdunlap@infradead.org, Jeremy Fitzhardinge , Arnd Bergmann , dl9pf@gmx.de, Andrew Morton , sparse@chrisli.org, Thomas Gleixner , "H. Peter Anvin" , Linux Kernel Mailing List , anil.s.keshavamurthy@intel.com, "David S. Miller" , "ananth@in.ibm.com" , Chris Wright , akataria@vmware.com, linux-tip-commits@vger.kernel.org, "yrl.pp-manager.tt@hitachi.com" Subject: Re: Re: [tip:perf/kprobes] kprobes: Introduce NOKPROBE_SYMBOL() macro to maintain kprobes blacklist References: <20140417081705.26341.96719.stgit@ltc230.yrl.intra.hitachi.co.jp> <5368B38B.5080908@hitachi.com> In-Reply-To: <5368B38B.5080908@hitachi.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org (2014/05/06 19:03), Masami Hiramatsu wrote: > (2014/05/06 5:48), Tony Luck wrote: >> This patch is in linux-next ("next-20140505") and I see a >> bunch of "Failed to find blacklist" messages when booting >> on ia64: >> >> Failed to find blacklist 0001013168300000 >> Failed to find blacklist 0001013000f0a000 >> Failed to find blacklist 000101315f70a000 >> Failed to find blacklist 000101324c80a000 >> Failed to find blacklist 0001013063f0a000 >> Failed to find blacklist 000101327800a000 >> Failed to find blacklist 0001013277f0a000 >> Failed to find blacklist 000101315a70a000 >> Failed to find blacklist 0001013277e0a000 >> Failed to find blacklist 000101305a20a000 >> Failed to find blacklist 0001013277d0a000 >> Failed to find blacklist 00010130bdc0a000 >> Failed to find blacklist 00010130dc20a000 >> Failed to find blacklist 000101309a00a000 >> Failed to find blacklist 0001013277c0a000 >> Failed to find blacklist 0001013277b0a000 >> Failed to find blacklist 0001013277a0a000 >> Failed to find blacklist 000101327790a000 >> Failed to find blacklist 000101303140a000 >> Failed to find blacklist 0001013a3280a000 >> >> What do these mean? > > Ah, I forgot that ia64 has function descriptor :( > That means kprobes initial code has failed to get correct > entry address of the blacklisted functions. > > In include/linux/kprobes.h, I defined NOKPROBE_SYMBOL to store > the addresses of blacklisted functions as below, > > #define __NOKPROBE_SYMBOL(fname) \ > static unsigned long __used \ > __attribute__((section("_kprobe_blacklist"))) \ > _kbl_addr_##fname = (unsigned long)fname; > #define NOKPROBE_SYMBOL(fname) __NOKPROBE_SYMBOL(fname) > > _kbl_addr_XX stores the address of the function, but on IA64, > it stores the address of function descriptor. > > Since those addresses are only used with kallsyms to lookup > function size, I think I should use a macro to store correct > function address instead of the address of function descriptor > on ia64 (and similar arch). > But I'm not sure which macro I should use... Is there any good way > to get the address of function, instead of function descriptor? Hmm, there is no general interface for retrieving the function entry address from function pointer. I'd like to propose constant_function_entry() macro for this purpose in linux/types.h (and arch-dep implementation will be in asm/types.h) BTW, as far as I can see, powerpc64 may have same problem. I'm not sure about powerpc64 ABI, and recently it seems that they introduced ABIv2 support. The problem is, it seems that ppc64 ABIv2 has two function entries and I don't know which entry should I use for kallsyms. Is that enough to return (unsigned long)fname always on ABIv2 ? At least on ppc64 ABIv1, I know I should return ((func_descr_t *)func)->entry ... Thank you, -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Research Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu.pt@hitachi.com