| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20151118124647.GU22729@kernel.org> Date: Wed, 18 Nov 2015 09:46:47 -0300 From: Arnaldo Carvalho de Melo <acme@...nel.org> To: Masami Hiramatsu <masami.hiramatsu.pt@...achi.com> Cc: Peter Zijlstra <a.p.zijlstra@...llo.nl>, linux-kernel@...r.kernel.org, Adrian Hunter <adrian.hunter@...el.com>, Ingo Molnar <mingo@...hat.com>, Namhyung Kim <namhyung@...nel.org>, Jiri Olsa <jolsa@...hat.com> Subject: Re: [PATCH perf/core 00/13] perf memory/refcnt leak fixes Em Wed, Nov 18, 2015 at 03:40:09PM +0900, Masami Hiramatsu escreveu: > Hi, > > Here is a series to fix some memory leaks and refcount > leaks on map and dso. This also includes the refcnt APIs > with backtrace debugging feature. Cool, I wonder if this could be usable in the kernel proper... Is there such a facility there? I'll check. But thanks for doing this work, I'll go thru the fixes first, then look at the debugging feature. - Arnaldo > The story has started from the posible memory leak report > reported by Wnag Nan. > I've tried to use valgrind to ensure the perf probe doesn't > have other memory leaks. The result is here: > > ---- > # valgrind ./perf probe vfs_read > ==17521== Memcheck, a memory error detector > ==17521== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. > ==17521== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info > ==17521== Command: ./perf probe vfs_read > ==17521== > Added new event: > probe:vfs_read (on vfs_read) > > You can now use it in all perf tools, such as: > > perf record -e probe:vfs_read -aR sleep 1 > > ==17521== > ==17521== HEAP SUMMARY: > ==17521== in use at exit: 3,512,761 bytes in 38,012 blocks > ==17521== total heap usage: 74,723 allocs, 36,711 frees, 24,014,927 > bytes allocated > ==17521== > ==17521== LEAK SUMMARY: > ==17521== definitely lost: 6,857 bytes in 49 blocks > ==17521== indirectly lost: 3,501,287 bytes in 37,891 blocks > ==17521== possibly lost: 0 bytes in 0 blocks > ==17521== still reachable: 4,617 bytes in 72 blocks > ==17521== suppressed: 0 bytes in 0 blocks > ==17521== Rerun with --leak-check=full to see details of leaked memory > ==17521== > ==17521== For counts of detected and suppressed errors, rerun with: -v > ==17521== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2) > ---- > > Oops! It leaked almost 4 MB memories. I've tried to find > the root causes, and what I've found is there are many > leaks in not only perf-probe specific code, but also maps > and dsos (and some other pieces). > > The first 3 patches are just fixing 'easy' memory leaks. However, > most of the leaks are caused by refcnt. Since valgrind seems not > able to debug this kind of issues, I introduced a hand-made refcnt > backtrace APIs for debugging. > The rest of patches are for fixing refcnt leak bugs and replcing > refcnt apis. > > After all, most of the issues are gone, except for just a few issues > in elfutils. I'll continue to investigate that. > > ---- > valgrind ./perf probe vfs_read > ==29521== Memcheck, a memory error detector > ==29521== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. > ==29521== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info > ==29521== Command: ./perf probe vfs_read > ==29521== > Added new event: > probe:vfs_read (on vfs_read) > > You can now use it in all perf tools, such as: > > perf record -e probe:vfs_read -aR sleep 1 > > ==29521== > ==29521== HEAP SUMMARY: > ==29521== in use at exit: 5,137 bytes in 75 blocks > ==29521== total heap usage: 74,723 allocs, 74,648 frees, 24,014,927 > bytes allocated > ==29521== > ==29521== LEAK SUMMARY: > ==29521== definitely lost: 520 bytes in 3 blocks > ==29521== indirectly lost: 0 bytes in 0 blocks > ==29521== possibly lost: 0 bytes in 0 blocks > ==29521== still reachable: 4,617 bytes in 72 blocks > ==29521== suppressed: 0 bytes in 0 blocks > ==29521== Rerun with --leak-check=full to see details of leaked memory > ==29521== > ==29521== For counts of detected and suppressed errors, rerun with: -v > ==29521== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2) > ---- > > Anyway, I decided to release these fixes and the debugging feature > because at least this will improve perf quality. > > Thank you, > > --- > > Masami Hiramatsu (13): > perf probe: Fix to free temporal Dwarf_Frame > perf: Make perf_exec_path always returns malloc'd string > perf: Introduce generic refcount APIs with debug feature > perf: make map to use refcnt > perf: Fix machine__findnew_module_map to put registered map > perf: Fix machine__destroy_kernel_maps to put vmlinux_maps > perf: Fix to destroy kernel maps when machine exits > perf: Fix to put new map after inserting to map_groups in dso__load_sym > perf: Make dso to use refcnt for debug > perf: Fix __dsos__addnew to put dso after adding it to the list > perf: Fix machine__create_kernel_maps to put kernel dso > perf: Fix machine__findnew_module_map to put dso > perf: Fix dso__load_sym to put dso > > > tools/perf/config/Makefile | 5 ++ > tools/perf/util/Build | 1 > tools/perf/util/dso.c | 9 ++- > tools/perf/util/exec_cmd.c | 20 ++++-- > tools/perf/util/exec_cmd.h | 5 +- > tools/perf/util/help.c | 6 +- > tools/perf/util/machine.c | 17 ++++- > tools/perf/util/map.c | 7 +- > tools/perf/util/map.h | 3 + > tools/perf/util/probe-finder.c | 9 ++- > tools/perf/util/refcnt.c | 125 ++++++++++++++++++++++++++++++++++++++++ > tools/perf/util/refcnt.h | 65 +++++++++++++++++++++ > tools/perf/util/symbol-elf.c | 4 + > 13 files changed, 250 insertions(+), 26 deletions(-) > create mode 100644 tools/perf/util/refcnt.c > create mode 100644 tools/perf/util/refcnt.h > > > -- > Masami HIRAMATSU > Linux Technology Research Center, System Productivity Research Dept. > Center for Technology Innovation - Systems Engineering > Hitachi, Ltd., Research & Development Group > E-mail: masami.hiramatsu.pt@...achi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists