1. 07 5月, 2014 5 次提交
  2. 23 4月, 2014 1 次提交
  3. 15 4月, 2014 1 次提交
  4. 10 4月, 2014 1 次提交
  5. 09 4月, 2014 2 次提交
    • M
      tracepoint: Fix sparse warnings in tracepoint.c · b725dfea
      Mathieu Desnoyers 提交于
      Fix the following sparse warnings:
      
        CHECK   kernel/tracepoint.c
      kernel/tracepoint.c:184:18: warning: incorrect type in assignment (different address spaces)
      kernel/tracepoint.c:184:18:    expected struct tracepoint_func *tp_funcs
      kernel/tracepoint.c:184:18:    got struct tracepoint_func [noderef] <asn:4>*funcs
      kernel/tracepoint.c:216:18: warning: incorrect type in assignment (different address spaces)
      kernel/tracepoint.c:216:18:    expected struct tracepoint_func *tp_funcs
      kernel/tracepoint.c:216:18:    got struct tracepoint_func [noderef] <asn:4>*funcs
      kernel/tracepoint.c:392:24: error: return expression in void function
        CC      kernel/tracepoint.o
      kernel/tracepoint.c: In function tracepoint_module_going:
      kernel/tracepoint.c:491:6: warning: symbol 'syscall_regfunc' was not declared. Should it be static?
      kernel/tracepoint.c:508:6: warning: symbol 'syscall_unregfunc' was not declared. Should it be static?
      
      Link: http://lkml.kernel.org/r/1397049883-28692-1-git-send-email-mathieu.desnoyers@efficios.comSigned-off-by: NMathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      b725dfea
    • M
      tracepoint: Use struct pointer instead of name hash for reg/unreg tracepoints · de7b2973
      Mathieu Desnoyers 提交于
      Register/unregister tracepoint probes with struct tracepoint pointer
      rather than tracepoint name.
      
      This change, which vastly simplifies tracepoint.c, has been proposed by
      Steven Rostedt. It also removes 8.8kB (mostly of text) to the vmlinux
      size.
      
      From this point on, the tracers need to pass a struct tracepoint pointer
      to probe register/unregister. A probe can now only be connected to a
      tracepoint that exists. Moreover, tracers are responsible for
      unregistering the probe before the module containing its associated
      tracepoint is unloaded.
      
         text    data     bss     dec     hex filename
      10443444        4282528 10391552        25117524        17f4354 vmlinux.orig
      10434930        4282848 10391552        25109330        17f2352 vmlinux
      
      Link: http://lkml.kernel.org/r/1396992381-23785-2-git-send-email-mathieu.desnoyers@efficios.com
      
      CC: Ingo Molnar <mingo@kernel.org>
      CC: Frederic Weisbecker <fweisbec@gmail.com>
      CC: Andrew Morton <akpm@linux-foundation.org>
      CC: Frank Ch. Eigler <fche@redhat.com>
      CC: Johannes Berg <johannes.berg@intel.com>
      Signed-off-by: NMathieu Desnoyers <mathieu.desnoyers@efficios.com>
      [ SDR - fixed return val in void func in tracepoint_module_going() ]
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      de7b2973
  6. 08 4月, 2014 1 次提交
  7. 27 3月, 2014 1 次提交
  8. 22 3月, 2014 1 次提交
  9. 21 3月, 2014 2 次提交
    • Q
      btrfs: Add trace for btrfs_workqueue alloc/destroy · c3a46891
      Qu Wenruo 提交于
      Since most of the btrfs_workqueue is printed as pointer address,
      for easier analysis, add trace for btrfs_workqueue alloc/destroy.
      So it is possible to determine the workqueue that a given work belongs
      to(by comparing the wq pointer address with alloc trace event).
      Signed-off-by: NQu Wenruo <quenruo@cn.fujitsu.com>
      Signed-off-by: NChris Mason <clm@fb.com>
      c3a46891
    • V
      tracing: Fix array size mismatch in format string · 87291347
      Vaibhav Nagarnaik 提交于
      In event format strings, the array size is reported in two locations.
      One in array subscript and then via the "size:" attribute. The values
      reported there have a mismatch.
      
      For e.g., in sched:sched_switch the prev_comm and next_comm character
      arrays have subscript values as [32] where as the actual field size is
      16.
      
      name: sched_switch
      ID: 301
      format:
              field:unsigned short common_type;       offset:0;       size:2; signed:0;
              field:unsigned char common_flags;       offset:2;       size:1; signed:0;
              field:unsigned char common_preempt_count;       offset:3;       size:1;signed:0;
              field:int common_pid;   offset:4;       size:4; signed:1;
      
              field:char prev_comm[32];       offset:8;       size:16;        signed:1;
              field:pid_t prev_pid;   offset:24;      size:4; signed:1;
              field:int prev_prio;    offset:28;      size:4; signed:1;
              field:long prev_state;  offset:32;      size:8; signed:1;
              field:char next_comm[32];       offset:40;      size:16;        signed:1;
              field:pid_t next_pid;   offset:56;      size:4; signed:1;
              field:int next_prio;    offset:60;      size:4; signed:1;
      
      After bisection, the following commit was blamed:
      92edca07 tracing: Use direct field, type and system names
      
      This commit removes the duplication of strings for field->name and
      field->type assuming that all the strings passed in
      __trace_define_field() are immutable. This is not true for arrays, where
      the type string is created in event_storage variable and field->type for
      all array fields points to event_storage.
      
      Use __stringify() to create a string constant for the type string.
      
      Also, get rid of event_storage and event_storage_mutex that are not
      needed anymore.
      
      also, an added benefit is that this reduces the overhead of events a bit more:
      
         text    data     bss     dec     hex filename
      8424787 2036472 1302528 11763787         b3804b vmlinux
      8420814 2036408 1302528 11759750         b37086 vmlinux.patched
      
      Link: http://lkml.kernel.org/r/1392349908-29685-1-git-send-email-vnagarnaik@google.com
      
      Cc: Laurent Chavey <chavey@google.com>
      Cc: stable@vger.kernel.org # 3.10+
      Signed-off-by: NVaibhav Nagarnaik <vnagarnaik@google.com>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      87291347
  10. 19 3月, 2014 3 次提交
  11. 14 3月, 2014 2 次提交
    • D
      i2c: Add message transfer tracepoints for SMBUS [ver #2] · 8a325997
      David Howells 提交于
      The SMBUS tracepoints can be enabled thusly:
      
      	echo 1 >/sys/kernel/debug/tracing/events/i2c/enable
      
      and will dump messages that can be viewed in /sys/kernel/debug/tracing/trace
      that look like:
      
               ... smbus_read: i2c-0 a=051 f=0000 c=fa BYTE_DATA
               ... smbus_reply: i2c-0 a=051 f=0000 c=fa BYTE_DATA l=1 [39]
               ... smbus_result: i2c-0 a=051 f=0000 c=fa BYTE_DATA rd res=0
      
      formatted as:
      
      	i2c-<adapter-nr>
      	a=<addr>
      	f=<flags>
      	c=<command>
      	<protocol-name>
      	<rd|wr>
      	res=<result>
      	l=<data-len>
      	[<data-block>]
      
      The adapters to be traced can be selected by something like:
      
      	echo adapter_nr==1 >/sys/kernel/debug/tracing/events/i2c/filter
      
      Note that this shares the same filter and enablement as i2c.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Reviewed-by: NSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      8a325997
    • D
      i2c: Add message transfer tracepoints for I2C · d9a83d62
      David Howells 提交于
      Add tracepoints into the I2C message transfer function to retrieve the message
      sent or received.  The following config options must be turned on to make use
      of the facility:
      
      	CONFIG_FTRACE
      	CONFIG_ENABLE_DEFAULT_TRACERS
      
      The I2C tracepoint can be enabled thusly:
      
      	echo 1 >/sys/kernel/debug/tracing/events/i2c/enable
      
      and will dump messages that can be viewed in /sys/kernel/debug/tracing/trace
      that look like:
      
      	... i2c_write: i2c-5 #0 a=044 f=0000 l=2 [02-14]
      	... i2c_read: i2c-5 #1 a=044 f=0001 l=4
      	... i2c_reply: i2c-5 #1 a=044 f=0001 l=4 [33-00-00-00]
      	... i2c_result: i2c-5 n=2 ret=2
      
      formatted as:
      
      	i2c-<adapter-nr>
      	#<message-array-index>
      	a=<addr>
      	f=<flags>
      	l=<datalen>
      	n=<message-array-size>
      	ret=<result>
      	[<data>]
      
      The operation is done between the i2c_write/i2c_read lines and the i2c_reply
      and i2c_result lines so that if the hardware hangs, the trace buffer can be
      consulted to determine the problematic operation.
      
      The adapters to be traced can be selected by something like:
      
      	echo adapter_nr==1 >/sys/kernel/debug/tracing/events/i2c/filter
      
      These changes are based on code from Steven Rostedt.
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Reviewed-by: NSteven Rostedt <rostedt@goodmis.org>
      [wsa: adapted path for 'enable' in the commit msg]
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      d9a83d62
  12. 13 3月, 2014 1 次提交
    • M
      Fix: module signature vs tracepoints: add new TAINT_UNSIGNED_MODULE · 66cc69e3
      Mathieu Desnoyers 提交于
      Users have reported being unable to trace non-signed modules loaded
      within a kernel supporting module signature.
      
      This is caused by tracepoint.c:tracepoint_module_coming() refusing to
      take into account tracepoints sitting within force-loaded modules
      (TAINT_FORCED_MODULE). The reason for this check, in the first place, is
      that a force-loaded module may have a struct module incompatible with
      the layout expected by the kernel, and can thus cause a kernel crash
      upon forced load of that module on a kernel with CONFIG_TRACEPOINTS=y.
      
      Tracepoints, however, specifically accept TAINT_OOT_MODULE and
      TAINT_CRAP, since those modules do not lead to the "very likely system
      crash" issue cited above for force-loaded modules.
      
      With kernels having CONFIG_MODULE_SIG=y (signed modules), a non-signed
      module is tainted re-using the TAINT_FORCED_MODULE taint flag.
      Unfortunately, this means that Tracepoints treat that module as a
      force-loaded module, and thus silently refuse to consider any tracepoint
      within this module.
      
      Since an unsigned module does not fit within the "very likely system
      crash" category of tainting, add a new TAINT_UNSIGNED_MODULE taint flag
      to specifically address this taint behavior, and accept those modules
      within Tracepoints. We use the letter 'X' as a taint flag character for
      a module being loaded that doesn't know how to sign its name (proposed
      by Steven Rostedt).
      
      Also add the missing 'O' entry to trace event show_module_flags() list
      for the sake of completeness.
      Signed-off-by: NMathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Acked-by: NSteven Rostedt <rostedt@goodmis.org>
      NAKed-by: NIngo Molnar <mingo@redhat.com>
      CC: Thomas Gleixner <tglx@linutronix.de>
      CC: David Howells <dhowells@redhat.com>
      CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      66cc69e3
  13. 11 3月, 2014 1 次提交
  14. 08 3月, 2014 1 次提交
    • D
      SUNRPC: Fix oops when trace sunrpc_task events in nfs client · 2ca310fc
      Ditang Chen 提交于
      When tracking sunrpc_task events in nfs client, the clnt pointer may be NULL.
      
      [  139.269266] BUG: unable to handle kernel NULL pointer dereference at 0000000000000004
      [  139.269915] IP: [<ffffffffa026f216>] ftrace_raw_event_rpc_task_running+0x86/0xf0 [sunrpc]
      [  139.269915] PGD 1d293067 PUD 1d294067 PMD 0
      [  139.269915] Oops: 0000 [#1] SMP
      [  139.269915] Modules linked in: nfsv4 dns_resolver nfs lockd sunrpc fscache sg ppdev e1000
      serio_raw pcspkr parport_pc parport i2c_piix4 i2c_core microcode xfs libcrc32c sd_mod sr_mod
      cdrom ata_generic crc_t10dif crct10dif_common pata_acpi ahci libahci ata_piix libata dm_mirror
      dm_region_hash dm_log dm_mod
      [  139.269915] CPU: 0 PID: 59 Comm: kworker/0:2 Not tainted 3.10.0-84.el7.x86_64 #1
      [  139.269915] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
      [  139.269915] Workqueue: rpciod rpc_async_schedule [sunrpc]
      [  139.269915] task: ffff88001b598000 ti: ffff88001b632000 task.ti: ffff88001b632000
      [  139.269915] RIP: 0010:[<ffffffffa026f216>]  [<ffffffffa026f216>] ftrace_raw_event_rpc_task_running+0x86/0xf0 [sunrpc]
      [  139.269915] RSP: 0018:ffff88001b633d70  EFLAGS: 00010206
      [  139.269915] RAX: ffff88001dfc5338 RBX: ffff88001cc37a00 RCX: ffff88001dfc5334
      [  139.269915] RDX: ffff88001dfc5338 RSI: 0000000000000000 RDI: ffff88001dfc533c
      [  139.269915] RBP: ffff88001b633db0 R08: 000000000000002c R09: 000000000000000a
      [  139.269915] R10: 0000000000062180 R11: 00000020759fb9dc R12: ffffffffa0292c20
      [  139.269915] R13: ffff88001dfc5334 R14: 0000000000000000 R15: 0000000000000000
      [  139.269915] FS:  0000000000000000(0000) GS:ffff88001fc00000(0000) knlGS:0000000000000000
      [  139.269915] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      [  139.269915] CR2: 0000000000000004 CR3: 000000001d290000 CR4: 00000000000006f0
      [  139.269915] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [  139.269915] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      [  139.269915] Stack:
      [  139.269915]  000000001b633d98 0000000000000246 ffff88001df1dc00 ffff88001cc37a00
      [  139.269915]  ffff88001bc35e60 0000000000000000 ffff88001ffa0a48 ffff88001bc35ee0
      [  139.269915]  ffff88001b633e08 ffffffffa02704b5 0000000000010000 ffff88001cc37a70
      [  139.269915] Call Trace:
      [  139.269915]  [<ffffffffa02704b5>] __rpc_execute+0x1d5/0x400 [sunrpc]
      [  139.269915]  [<ffffffffa0270706>] rpc_async_schedule+0x26/0x30 [sunrpc]
      [  139.269915]  [<ffffffff8107867b>] process_one_work+0x17b/0x460
      [  139.269915]  [<ffffffff8107942b>] worker_thread+0x11b/0x400
      [  139.269915]  [<ffffffff81079310>] ? rescuer_thread+0x3e0/0x3e0
      [  139.269915]  [<ffffffff8107fc80>] kthread+0xc0/0xd0
      [  139.269915]  [<ffffffff8107fbc0>] ? kthread_create_on_node+0x110/0x110
      [  139.269915]  [<ffffffff815d122c>] ret_from_fork+0x7c/0xb0
      [  139.269915]  [<ffffffff8107fbc0>] ? kthread_create_on_node+0x110/0x110
      [  139.269915] Code: 4c 8b 45 c8 48 8d 7d d0 89 4d c4 41 89 c9 b9 28 00 00 00 e8 9d b4 e9
      e0 48 85 c0 49 89 c5 74 a2 48 89 c7 e8 9d 3f e9 e0 48 89 c2 <41> 8b 46 04 48 8b 7d d0 4c
      89 e9 4c 89 e6 89 42 0c 0f b7 83 d4
      [  139.269915] RIP  [<ffffffffa026f216>] ftrace_raw_event_rpc_task_running+0x86/0xf0 [sunrpc]
      [  139.269915]  RSP <ffff88001b633d70>
      [  139.269915] CR2: 0000000000000004
      [  140.946406] ---[ end trace ba486328b98d7622 ]---
      Signed-off-by: NDitang Chen <chendt.fnst@cn.fujitsu.com>
      Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
      2ca310fc
  15. 07 3月, 2014 7 次提交
  16. 06 3月, 2014 2 次提交
  17. 24 2月, 2014 1 次提交
  18. 22 2月, 2014 3 次提交
  19. 19 2月, 2014 1 次提交
  20. 18 2月, 2014 1 次提交
  21. 13 2月, 2014 1 次提交
  22. 11 2月, 2014 1 次提交