| 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: <1435169294-4225-1-git-send-email-jbacik@fb.com> Date: Wed, 24 Jun 2015 11:08:14 -0700 From: Josef Bacik <jbacik@...com> To: <kernel-team@...com>, <linux-kernel@...r.kernel.org>, <rostedt@...dmis.org> Subject: [PATCH] trace-cmd: add documentation for trace-cmd-kmemleak This adds the manpage for trace-cmd-kmemleak. Thanks, Signed-off-by: Josef Bacik <jbacik@...com> --- Documentation/trace-cmd-kmemleak.1.txt | 226 +++++++++++++++++++++++++++++++++ 1 file changed, 226 insertions(+) create mode 100644 Documentation/trace-cmd-kmemleak.1.txt diff --git a/Documentation/trace-cmd-kmemleak.1.txt b/Documentation/trace-cmd-kmemleak.1.txt new file mode 100644 index 0000000..e945096 --- /dev/null +++ b/Documentation/trace-cmd-kmemleak.1.txt @@ -0,0 +1,226 @@ +TRACE-CMD-KMEMLEAK(1) +==================== + +NAME +---- +trace-cmd-kmemleak - watch kernel allocations for possible leaks + +SYNOPSIS +-------- +*trace-cmd kmemleak ['OPTIONS']* ['command'] + +DESCRIPTION +----------- +The trace-cmd(1) kmemleak will start tracing just like trace-cmd-record(1) does, +excep that it does not write to a file, but instead, it will read the kernel +allocation events as they happen and update accounting of the events. When the +trace is finished it will report the total number of bytes leaked by their +object size along with the stack traces of all of the allocators and the number +of times that stack trace was used to make an allocation. + +The kernel makes slab allocations in two ways, one out of the generic +kmalloc-<size> pools or out of a object specific cache, for example ext4-inode. +This tool will keep track of pools of same sized objects and report the total +lost by the object size. This unfortunately could group kmalloc-<size> pools +with the object specific object pools, but the stack traces should help +indicate what pool is being used. + +The advantage of this tool is that we do not write the events to disk, so you +can run this profiler over long periods of time with minimal overhead, we only +keep currently outstanding allocations in memory. That does mean that if you do +some operation that generates a lot of long lifetime slab objects (such as +running find /) that the memory overhead could be higher than normal. + +You can get current status of the leaks by doing kill -SIGUSR2 <trace-cmd pid>. + +OPTIONS +------- +There are no kmemleak specific options, but the trace-cmd-record(1) options can +be used. + +EXAMPLES +-------- + + --- +# trace-cmd kmemleak -- sleep 5 + [..] +Printing kmemleak summary +Leaked 16384 bytes of size 16384 + Stack count: 1 + ftrace_raw_event_kmem_alloc (0xffffffff811c0ccd) + kmalloc_order_trace (0xffffffff811c02db) + tracing_buffers_open (0xffffffff8116472e) + do_dentry_open (0xffffffff81216ce2) + vfs_open (0xffffffff81216f99) + do_last (0xffffffff81227107) + path_openat (0xffffffff81229eb7) + do_filp_open (0xffffffff8122bc49) + do_sys_open (0xffffffff8121897b) + SyS_open (0xffffffff81218aae) + system_call_fastpath (0xffffffff817752c9) + 0xffffffffffffffff +Leaked 2368 bytes of size 32 + Stack count: 72 + ftrace_raw_event_kmem_alloc (0xffffffff811c0ccd) + kmem_cache_alloc_trace (0xffffffff811fbabb) + tracing_buffers_splice_read (0xffffffff81163e6f) + do_splice_to (0xffffffff81248d5d) + SyS_splice (0xffffffff8124b5e6) + system_call_fastpath (0xffffffff817752c9) + 0xffffffffffffffff + irq_stack_union (0x0) + Stack count: 1 + ftrace_raw_event_kmem_alloc (0xffffffff811c0ccd) + __kmalloc_track_caller (0xffffffff811fe6ab) + kmemdup (0xffffffff811b9dd0) + selinux_cred_prepare (0xffffffff81323daf) + security_prepare_creds (0xffffffff8131f676) + prepare_creds (0xffffffff810bc320) + prepare_exec_creds (0xffffffff810bc843) + prepare_bprm_creds (0xffffffff81220f9d) + do_execveat_common.isra.29 (0xffffffff812210eb) + SyS_execve (0xffffffff8122199a) + stub_execve (0xffffffff81775859) + 0xffffffffffffffff + Stack count: 1 + ftrace_raw_event_kmem_alloc (0xffffffff811c0ccd) + __kmalloc (0xffffffff811fc48b) + shmem_initxattrs (0xffffffff811b6092) + security_inode_init_security (0xffffffff8131eb0c) + shmem_mknod (0xffffffff811b5761) + shmem_create (0xffffffff811b5818) + vfs_create (0xffffffff812258f5) + do_last (0xffffffff812276d8) + path_openat (0xffffffff81229eb7) + do_filp_open (0xffffffff8122bc49) + do_sys_open (0xffffffff8121897b) + SyS_open (0xffffffff81218aae) + system_call_fastpath (0xffffffff817752c9) + 0xffffffffffffffff +Leaked 1024 bytes of size 1024 + Stack count: 1 + ftrace_raw_event_kmem_alloc (0xffffffff811c0ccd) + kmem_cache_alloc_trace (0xffffffff811fbabb) + alloc_pipe_info (0xffffffff81222842) + create_pipe_files (0xffffffff81222da5) + __do_pipe_flags (0xffffffff81222fb9) + SyS_pipe (0xffffffff812231bf) + system_call_fastpath (0xffffffff817752c9) + 0xffffffffffffffff +Leaked 512 bytes of size 512 + Stack count: 1 + ftrace_raw_event_kmem_alloc (0xffffffff811c0ccd) + __kmalloc (0xffffffff811fc48b) + do_sys_poll (0xffffffff81230239) + SyS_ppoll (0xffffffff81230a5f) + system_call_fastpath (0xffffffff817752c9) + 0xffffffffffffffff + irq_stack_union (0x0) + irq_stack_union (0x0) +Leaked 192 bytes of size 192 + Stack count: 1 + ftrace_raw_event_kmem_alloc (0xffffffff811c0ccd) + kmem_cache_alloc_trace (0xffffffff811fbabb) + alloc_pipe_info (0xffffffff81222824) + create_pipe_files (0xffffffff81222da5) + __do_pipe_flags (0xffffffff81222fb9) + SyS_pipe (0xffffffff812231bf) + system_call_fastpath (0xffffffff817752c9) + 0xffffffffffffffff +Leaked 192 bytes of size 96 + Stack count: 1 + ftrace_raw_event_kmem_alloc (0xffffffff811c0ccd) + __kmalloc (0xffffffff811fc48b) + simple_xattr_alloc (0xffffffff8124141f) + shmem_initxattrs (0xffffffff811b6070) + security_inode_init_security (0xffffffff8131eb0c) + shmem_mknod (0xffffffff811b5761) + shmem_create (0xffffffff811b5818) + vfs_create (0xffffffff812258f5) + do_last (0xffffffff812276d8) + path_openat (0xffffffff81229eb7) + do_filp_open (0xffffffff8122bc49) + do_sys_open (0xffffffff8121897b) + SyS_open (0xffffffff81218aae) + system_call_fastpath (0xffffffff817752c9) + 0xffffffffffffffff + Stack count: 1 + ftrace_raw_event_kmem_alloc (0xffffffff811c0ccd) + kmem_cache_alloc_trace (0xffffffff811fbabb) + intel_ring_begin (0xffffffffa019f026) + gen7_render_ring_flush (0xffffffffa01a0478) + intel_ring_invalidate_all_caches (0xffffffffa01a2302) + i915_gem_ringbuffer_submission (0xffffffffa0177893) + i915_gem_do_execbuffer.isra.22 (0xffffffffa0177090) + i915_gem_execbuffer2 (0xffffffffa0178589) + drm_ioctl (0xffffffffa0074a9f) + do_vfs_ioctl (0xffffffff8122e318) + SyS_ioctl (0xffffffff8122e5a1) + system_call_fastpath (0xffffffff817752c9) + 0xffffffffffffffff +Leaked 64 bytes of size 16 + Stack count: 2 + ftrace_raw_event_kmem_alloc (0xffffffff811c0ccd) + kmem_cache_alloc_trace (0xffffffff811fbabb) + selinux_file_alloc_security (0xffffffff8132640c) + security_file_alloc (0xffffffff8131f3b6) + get_empty_filp (0xffffffff8121b85a) + path_openat (0xffffffff81229e61) + do_filp_open (0xffffffff8122bc49) + do_sys_open (0xffffffff8121897b) + SyS_open (0xffffffff81218aae) + system_call_fastpath (0xffffffff817752c9) + 0xffffffffffffffff + Stack count: 1 + ftrace_raw_event_kmem_alloc (0xffffffff811c0ccd) + kmem_cache_alloc_trace (0xffffffff811fbabb) + selinux_file_alloc_security (0xffffffff8132640c) + security_file_alloc (0xffffffff8131f3b6) + get_empty_filp (0xffffffff8121b85a) + alloc_file (0xffffffff8121b99f) + create_pipe_files (0xffffffff81222e80) + __do_pipe_flags (0xffffffff81222fb9) + SyS_pipe (0xffffffff812231bf) + system_call_fastpath (0xffffffff817752c9) + 0xffffffffffffffff + Stack count: 1 + ftrace_raw_event_kmem_alloc (0xffffffff811c0ccd) + kmem_cache_alloc_trace (0xffffffff811fbabb) + selinux_file_alloc_security (0xffffffff8132640c) + security_file_alloc (0xffffffff8131f3b6) + get_empty_filp (0xffffffff8121b85a) + alloc_file (0xffffffff8121b99f) + create_pipe_files (0xffffffff81222ec3) + __do_pipe_flags (0xffffffff81222fb9) + SyS_pipe (0xffffffff812231bf) + system_call_fastpath (0xffffffff817752c9) + 0xffffffffffffffff + --- + +The output is very simple. Of course none of these are actual leaks, the object +lifetime is just longer than the run of the tracing. The summary output shows +the basic information: + + Leaked 64 bytes of size 16 + +We leaked 64 total bytes of 16 byte objects, and then you can see the stack +traces of the allocators below that. There are 4 total allocations all adding +up to 64 bytes. + +SEE ALSO +-------- +trace-cmd(1), trace-cmd-record(1) + +AUTHOR +------ +Written by Josef Bacik, <jbacik@...com> + +RESOURCES +--------- +git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/trace-cmd.git + +COPYING +------- +Copyright \(C) 2015 Facebook. Free use of this software is granted under +the terms of the GNU Public License (GPL). + -- 2.1.0 -- 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