Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932975AbbKFNnO (ORCPT ); Fri, 6 Nov 2015 08:43:14 -0500 Received: from mail.kernel.org ([198.145.29.136]:36304 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932883AbbKFNnM (ORCPT ); Fri, 6 Nov 2015 08:43:12 -0500 Date: Fri, 6 Nov 2015 10:43:03 -0300 From: Arnaldo Carvalho de Melo To: "Wangnan (F)" Cc: Adrian Hunter , =?utf-8?B?5bmz5p2+6ZuF5bezIC8gSElSQU1BVFXvvIxNQVNBTUk=?= , "'ltc-kernel@ml.yrl.intra.hitachi.co.jp'" , "namhyung@kernel.org" , "lizefan@huawei.com" , "pi3orama@163.com" , "linux-kernel@vger.kernel.org" , "jolsa@kernel.org" Subject: Re: [PATCH 2/2] perf tools: Fix find_perf_probe_point_from_map() which incorrectly returns success Message-ID: <20151106134303.GC13236@kernel.org> References: <1446729565-27592-1-git-send-email-wangnan0@huawei.com> <1446729565-27592-3-git-send-email-wangnan0@huawei.com> <50399556C9727B4D88A595C8584AAB3752604844@GSjpTKYDCembx32.service.hitachi.net> <20151105160000.GX13236@kernel.org> <50399556C9727B4D88A595C8584AAB3752606DC9@GSjpTKYDCembx32.service.hitachi.net> <50399556C9727B4D88A595C8584AAB37526070A4@GSjpTKYDCembx32.service.hitachi.net> <563C6539.7030605@huawei.com> <563C726A.4060209@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <563C726A.4060209@huawei.com> X-Url: http://acmel.wordpress.com User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4794 Lines: 128 Em Fri, Nov 06, 2015 at 05:27:06PM +0800, Wangnan (F) escreveu: > On 2015/11/6 16:30, Wangnan (F) wrote: > >On 2015/11/6 15:12, 平松雅巳 / HIRAMATU，MASAMI wrote: > >>From: acme@kernel.org [mailto:acme@kernel.org] > >>>>Em Thu, Nov 05, 2015 at 02:08:48PM +0000, 平松雅巳 / HIRAMATU，MASAMI escreveu: > >>>>>From: Wang Nan [mailto:wangnan0@huawei.com] > [SNIP] > >>Ah, finally I got what happened. I guess the problem may happen when > >>we put a probe on the kernel somewhere outside of any functions and > >>run "perf probe -l". > >>I think it should not be allowed to put the probe outside any symbol. > >>The background is here, at first "perf-probe -a somewhere" defines a > >>probe in the kernel but its address is relative from "_text". (thus, > >>vfs_read becomes "_text+2348080" > >> for example). Since it is not readable by human, perf probe -l tries > >>to get an appropriate > >>symbol from the "_text+OFFSET". > >>For the purpose, the first kernel_get_symbol_address_by_name() is for > >>translating _text to > >>an address, and the second __find_kernel_function() is for finding a > >>symbol from the > >>address+OFFSET. > >>Then, if the address+OFFSET is out of the symbol map, the second one can > >>fail. > >>This means the first symbol and the second symbol is not same. > >>So, the direction of Wang solution is good :). Just a cleanup is > >>required. > >I also tried to finger out the problem for all day and made some progress. > >It is another > >problem. It happeneds when probing an address reside in a module on > >aarch64 system. > > > >On my aarch64 system I use kcore. Different from x86, on aarch64, modules > >address is lower > >than normal kernel. For example: > > > >On x86_64: > > > ># readelf -a /proc/kcore > > > > Type Offset VirtAddr PhysAddr > > FileSiz MemSiz Flags Align > > ... > > LOAD 0x00007fff81003000 0xffffffff81000000 0x0000000000000000 > ><-- kernel > > 0x0000000001026000 0x0000000001026000 RWE 1000 > > LOAD 0x00007fffa0003000 0xffffffffa0000000 0x0000000000000000 > ><-- module > > 0x000000005f000000 0x000000005f000000 RWE 1000 > > > >On aarch64: > > > > Type Offset VirtAddr PhysAddr > > FileSiz MemSiz Flags Align > > ... > > LOAD 0x0000000000002000 0xffffffc000000000 0x0000000000000000 > ><-- kernel > > 0x000000007fc00000 0x000000007fc00000 RWE 1000 > > LOAD 0xfffffffffc002000 0xffffffbffc000000 0x0000000000000000 > ><-- module > > 0x0000000004000000 0x0000000004000000 RWE 1000 > > > >See? On aarch64, Offset field of module address area is negative. > > > > One thing should be noticed that, even if normal kernel code and modules use > different > 'struct map', they share a same dso. Please see dso__load_kcore, notice how > it initialize > parameters (md) before calling file__read_maps(). > > >Which causes a problem in dso__split_kallsyms_for_kcore(): when it > >adjusting symbols > >using "pos->start -= curr_map->start - curr_map->pgoff", the relative > >order between > >module functions and normal kernel function is changed. > > > >For example: > > > >funca at 0xffffffc00021b428 is a normal kernel function. > >funcb at 0xffffffbffc000000 is a function in kernel. > > > >During parsing /proc/kallsyms, address of funca > address of funcb. > >However, after the adjusting: > >funca becomes: > >0xffffffc00021b428 - (0xffffffc000000000 - 0x2000) = 0x21d428 > >funcb becomes: > >0xffffffbffc000000 - (0xffffffbffc000000 - 0xfffffffffc002000) = > >0xfffffffffc002000 > >address of funca < address of funcb. > >Unfortunately, the rbtree is not adjusted in this case. > Even if they are in different maps, they share a same dso here, so a same > rbtree. Yeah, see the answer to the patch you sent, we can't change the symbols in a DSO, as it may be shared by multiple maps (think about glibc and prelink, even without prelink) the same applies for kernel modules, that we represent in the same way, and in at least one case, i.e. split kallsyms for modules, core kernel, etc we share the same dso by multiple maps, so any adjustment that needs to be done should be done to the map members, not to the dso ones. CCing Adrian, that originally wrote the kcore code, but IIRC there are other places that touch sym-> (thus dso internal state) instead of adjusting map members :-\ - Arnaldo -- 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/