[PATCH] trace-cmd: add documentation for trace-cmd-kmemleak

From: Josef Bacik
Date: Wed Jun 24 2015 - 14:08:34 EST

Next message: Aldo Iljazi: "[PATCH] Staging:rtl8192u: fixed coding style issues"
Previous message: Peter Zijlstra: "Re: [RFC][PATCH 12/13] stop_machine: Remove lglock"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

This adds the manpage for trace-cmd-kmemleak. Thanks,

Signed-off-by: Josef Bacik <jbacik@xxxxxx>
---
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@xxxxxx>
+
+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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Next message: Aldo Iljazi: "[PATCH] Staging:rtl8192u: fixed coding style issues"
Previous message: Peter Zijlstra: "Re: [RFC][PATCH 12/13] stop_machine: Remove lglock"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]