Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753592AbbLJLEe (ORCPT ); Thu, 10 Dec 2015 06:04:34 -0500 Received: from mail7.hitachi.co.jp ([133.145.228.42]:35405 "EHLO mail7.hitachi.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751740AbbLJLEb convert rfc822-to-8bit (ORCPT ); Thu, 10 Dec 2015 06:04:31 -0500 From: =?iso-2022-jp?B?GyRCSj8+PjJtTCYbKEIgLyBISVJBTUFUVRskQiEkGyhCTUFTQU1J?= To: "'Arnaldo Carvalho de Melo'" CC: Peter Zijlstra , Adrian Hunter , "linux-kernel@vger.kernel.org" , "linux-perf-users@vger.kernel.org" , Ingo Molnar , "Namhyung Kim" , Jiri Olsa , Wang Nan , Alexei Starovoitov Subject: RE: [PATCH perf/core 00/22] perf refcnt debugger API and fixes Thread-Topic: [PATCH perf/core 00/22] perf refcnt debugger API and fixes Thread-Index: AQHRMifqdrp25x+uR0WYuBPwTEPEhp7CE3gAgAGJXGA= Date: Thu, 10 Dec 2015 11:04:27 +0000 Message-ID: <50399556C9727B4D88A595C8584AAB375264FB48@GSjpTKYDCembx32.service.hitachi.net> References: <20151209021047.10245.8918.stgit@localhost.localdomain> <20151209134138.GB15864@kernel.org> In-Reply-To: <20151209134138.GB15864@kernel.org> Accept-Language: ja-JP, en-US Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.198.219.40] Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2921 Lines: 79 >From: Arnaldo Carvalho de Melo [mailto:acme@kernel.org] > >Em Wed, Dec 09, 2015 at 11:10:48AM +0900, Masami Hiramatsu escreveu: >> Hi Arnaldo, >> >> Here is a series of patches for perf refcnt debugger and >> some fixes. >> >> In this series I've replaced all atomic reference counters >> with the refcnt interface, including dso, map, map_groups, >> thread, cpu_map, comm_str, cgroup_sel, thread_map, and >> perf_mmap. >> >> refcnt debugger (or refcnt leak checker) >> =============== >> >> At first, note that this change doesn't affect any compiled >> code unless building with REFCNT_DEBUG=1 (see macros in >> refcnt.h). So, this feature is only enabled in the debug binary. >> But before releasing, we can ensure that all objects are safely >> reclaimed before exit in -rc phase. > >That helps and is finding bugs and is really great stuff, thank you! > >But I wonder if we couldn't get the same results on an unmodified binary >by using things like 'perf probe', the BPF code we're introducing, have >you thought about this possibility? That's possible, but it will require pre-analysis of the binary, because refcnt interface is not fixed API like a "systemcall" (moreover, it could be just a non-atomic variable). Thus we need a kind of "annotation" event by source code level. > >I.e. trying to use 'perf probe' to do this would help in using the same >technique in other code bases where we can't change the sources, etc. > >For perf we could perhaps use a 'noinline' on the __get/__put >operations, so that we could have the right places to hook using >uprobes, other codebases would have to rely in the 'perf probe' >infrastructure that knows where inlines were expanded, etc. > >Such a toold could work like: > > perf dbgrefcnt ~/bin/perf thread This works only for the binary which is coded as you said. I actually doubt that this is universal solution. We'd better introduce librefcnt.so if you need more general solution, so that we can fix the refcnt API and we can also hook the interface easily. But with this way, we don't need ebpf/uprobes anymore, since we've already have LD_PRELOAD (like valgrind does). :( So, IMHO, using ebpf and perf probe for this issue sounds like using a sledge‐hammer... Thanks, > >And it would look up thread__get and thread__put(), create an eBPF map >where to store the needed tracking data structures, and use the same >techniques you used, asking for backtraces using the perf >infrastructure, etc. > >We would be using this opportunity to improve the 'perf probe' and the >eBPF infrastructures we're putting in place, and having something that >could be used in other codebases, not just perf. > -- 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/