1. 13 Jan, 2014 1 commit
    • Steven Rostedt (Red Hat)'s avatar
      ftrace: Have function graph only trace based on global_ops filters · 23a8e844
      Steven Rostedt (Red Hat) authored
      Doing some different tests, I discovered that function graph tracing, when
      filtered via the set_ftrace_filter and set_ftrace_notrace files, does
      not always keep with them if another function ftrace_ops is registered
      to trace functions.
      
      The reason is that function graph just happens to trace all functions
      that the function tracer enables. When there was only one user of
      function tracing, the function graph tracer did not need to worry about
      being called by functions that it did not want to trace. But now that there
      are other users, this becomes a problem.
      
      For example, one just needs to do the following:
      
       # cd /sys/kernel/debug/tracing
       # echo schedule > set_ftrace_filter
       # echo function_graph > current_tracer
       # cat trace
      [..]
       0)               |  schedule() {
       ------------------------------------------
       0)    <idle>-0    =>   rcu_pre-7
       ------------------------------------------
      
       0) ! 2980.314 us |  }
       0)               |  schedule() {
       ------------------------------------------
       0)   rcu_pre-7    =>    <idle>-0
       ------------------------------------------
      
       0) + 20.701 us   |  }
      
       # echo 1 > /proc/sys/kernel/stack_tracer_enabled
       # cat trace
      [..]
       1) + 20.825 us   |      }
       1) + 21.651 us   |    }
       1) + 30.924 us   |  } /* SyS_ioctl */
       1)               |  do_page_fault() {
       1)               |    __do_page_fault() {
       1)   0.274 us    |      down_read_trylock();
       1)   0.098 us    |      find_vma();
       1)               |      handle_mm_fault() {
       1)               |        _raw_spin_lock() {
       1)   0.102 us    |          preempt_count_add();
       1)   0.097 us    |          do_raw_spin_lock();
       1)   2.173 us    |        }
       1)               |        do_wp_page() {
       1)   0.079 us    |          vm_normal_page();
       1)   0.086 us    |          reuse_swap_page();
       1)   0.076 us    |          page_move_anon_rmap();
       1)               |          unlock_page() {
       1)   0.082 us    |            page_waitqueue();
       1)   0.086 us    |            __wake_up_bit();
       1)   1.801 us    |          }
       1)   0.075 us    |          ptep_set_access_flags();
       1)               |          _raw_spin_unlock() {
       1)   0.098 us    |            do_raw_spin_unlock();
       1)   0.105 us    |            preempt_count_sub();
       1)   1.884 us    |          }
       1)   9.149 us    |        }
       1) + 13.083 us   |      }
       1)   0.146 us    |      up_read();
      
      When the stack tracer was enabled, it enabled all functions to be traced, which
      now the function graph tracer also traces. This is a side effect that should
      not occur.
      
      To fix this a test is added when the function tracing is changed, as well as when
      the graph tracer is enabled, to see if anything other than the ftrace global_ops
      function tracer is enabled. If so, then the graph tracer calls a test trampoline
      that will look at the function that is being traced and compare it with the
      filters defined by the global_ops.
      
      As an optimization, if there's no other function tracers registered, or if
      the only registered function tracers also use the global ops, the function
      graph infrastructure will call the registered function graph callback directly
      and not go through the test trampoline.
      
      Cc: stable@vger.kernel.org # 3.3+
      Fixes: d2d45c7a "tracing: Have stack_tracer use a separate list of functions"
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      23a8e844
  2. 10 Jan, 2014 4 commits
  3. 06 Jan, 2014 2 commits
  4. 03 Jan, 2014 4 commits
    • Namhyung Kim's avatar
      tracing/probes: Fix build break on !CONFIG_KPROBE_EVENT · e0d18fe0
      Namhyung Kim authored
      When kprobe-based dynamic event tracer is not enabled, it caused
      following build error:
      
         kernel/built-in.o: In function `traceprobe_update_arg':
         (.text+0x10c8dd): undefined reference to `fetch_symbol_u8'
         kernel/built-in.o: In function `traceprobe_update_arg':
         (.text+0x10c8e9): undefined reference to `fetch_symbol_u16'
         kernel/built-in.o: In function `traceprobe_update_arg':
         (.text+0x10c8f5): undefined reference to `fetch_symbol_u32'
         kernel/built-in.o: In function `traceprobe_update_arg':
         (.text+0x10c901): undefined reference to `fetch_symbol_u64'
         kernel/built-in.o: In function `traceprobe_update_arg':
         (.text+0x10c909): undefined reference to `fetch_symbol_string'
         kernel/built-in.o: In function `traceprobe_update_arg':
         (.text+0x10c913): undefined reference to `fetch_symbol_string_size'
         ...
      
      It was due to the fetch methods are referred from CHECK_FETCH_FUNCS
      macro and since it was only defined in trace_kprobe.c.  Move NULL
      definition of such fetch functions to the header file.
      
      Note, it also requires CONFIG_BRANCH_PROFILING enabled to trigger
      this failure as well. This is because the "fetch_symbol_*" variables
      are referenced in a "else if" statement that will only call
      update_symbol_cache(), which is a static inline stub function
      when CONFIG_KPROBE_EVENT is not enabled. gcc is smart enough
      to optimize this "else if" out and that also removes the code that
      references the undefined variables.
      
      But when BRANCH_PROFILING is enabled, it fools gcc into keeping
      the if statement around and thus references the undefined symbols
      and fails to build.
      Reported-by: default avatarkbuild test robot <fengguang.wu@intel.com>
      Signed-off-by: default avatarNamhyung Kim <namhyung@kernel.org>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      e0d18fe0
    • Namhyung Kim's avatar
      tracing/uprobes: Add @+file_offset fetch method · b7e0bf34
      Namhyung Kim authored
      Enable to fetch data from a file offset.  Currently it only supports
      fetching from same binary uprobe set.  It'll translate the file offset
      to a proper virtual address in the process.
      
      The syntax is "@+OFFSET" as it does similar to normal memory fetching
      (@ADDR) which does no address translation.
      Suggested-by: default avatarOleg Nesterov <oleg@redhat.com>
      Acked-by: default avatarMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Acked-by: default avatarOleg Nesterov <oleg@redhat.com>
      Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
      Cc: zhangwei(Jovi) <jovi.zhangwei@huawei.com>
      Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
      Signed-off-by: default avatarNamhyung Kim <namhyung@kernel.org>
      b7e0bf34
    • Oleg Nesterov's avatar
      uprobes: Allocate ->utask before handler_chain() for tracing handlers · 72fd293a
      Oleg Nesterov authored
      uprobe_trace_print() and uprobe_perf_print() need to pass the additional
      info to call_fetch() methods, currently there is no simple way to do this.
      
      current->utask looks like a natural place to hold this info, but we need
      to allocate it before handler_chain().
      
      This is a bit unfortunate, perhaps we will find a better solution later,
      but this is simple and should work right now.
      Signed-off-by: default avatarOleg Nesterov <oleg@redhat.com>
      Acked-by: default avatarMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Acked-by: default avatarOleg Nesterov <oleg@redhat.com>
      Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
      Signed-off-by: default avatarNamhyung Kim <namhyung@kernel.org>
      72fd293a
    • Namhyung Kim's avatar
      tracing/uprobes: Add support for full argument access methods · b079d374
      Namhyung Kim authored
      Enable to fetch other types of argument for the uprobes.  IOW, we can
      access stack, memory, deref, bitfield and retval from uprobes now.
      
      The format for the argument types are same as kprobes (but @SYMBOL
      type is not supported for uprobes), i.e:
      
        @ADDR   : Fetch memory at ADDR
        $stackN : Fetch Nth entry of stack (N >= 0)
        $stack  : Fetch stack address
        $retval : Fetch return value
        +|-offs(FETCHARG) : Fetch memory at FETCHARG +|- offs address
      
      Note that the retval only can be used with uretprobes.
      Original-patch-by: default avatarHyeoncheol Lee <cheol.lee@lge.com>
      Acked-by: default avatarMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Acked-by: default avatarOleg Nesterov <oleg@redhat.com>
      Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: zhangwei(Jovi) <jovi.zhangwei@huawei.com>
      Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
      Signed-off-by: default avatarHyeoncheol Lee <cheol.lee@lge.com>
      Signed-off-by: default avatarNamhyung Kim <namhyung@kernel.org>
      b079d374
  5. 02 Jan, 2014 16 commits
  6. 22 Dec, 2013 6 commits
    • Tom Zanussi's avatar
      tracing: Add documentation for trace event triggers · ac38fb85
      Tom Zanussi authored
      Provide a basic overview of trace event triggers and document the
      available trigger commands, along with a few simple examples.
      
      Link: http://lkml.kernel.org/r/2595dd9196d7b553049611f2a3f849ca75d650a2.1382622043.git.tom.zanussi@linux.intel.comSigned-off-by: default avatarTom Zanussi <tom.zanussi@linux.intel.com>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      ac38fb85
    • Tom Zanussi's avatar
      tracing: Add and use generic set_trigger_filter() implementation · bac5fb97
      Tom Zanussi authored
      Add a generic event_command.set_trigger_filter() op implementation and
      have the current set of trigger commands use it - this essentially
      gives them all support for filters.
      
      Syntactically, filters are supported by adding 'if <filter>' just
      after the command, in which case only events matching the filter will
      invoke the trigger.  For example, to add a filter to an
      enable/disable_event command:
      
          echo 'enable_event:system:event if common_pid == 999' > \
                    .../othersys/otherevent/trigger
      
      The above command will only enable the system:event event if the
      common_pid field in the othersys:otherevent event is 999.
      
      As another example, to add a filter to a stacktrace command:
      
          echo 'stacktrace if common_pid == 999' > \
                         .../somesys/someevent/trigger
      
      The above command will only trigger a stacktrace if the common_pid
      field in the event is 999.
      
      The filter syntax is the same as that described in the 'Event
      filtering' section of Documentation/trace/events.txt.
      
      Because triggers can now use filters, the trigger-invoking logic needs
      to be moved in those cases - e.g. for ftrace_raw_event_calls, if a
      trigger has a filter associated with it, the trigger invocation now
      needs to happen after the { assign; } part of the call, in order for
      the trigger condition to be tested.
      
      There's still a SOFT_DISABLED-only check at the top of e.g. the
      ftrace_raw_events function, so when an event is soft disabled but not
      because of the presence of a trigger, the original SOFT_DISABLED
      behavior remains unchanged.
      
      There's also a bit of trickiness in that some triggers need to avoid
      being invoked while an event is currently in the process of being
      logged, since the trigger may itself log data into the trace buffer.
      Thus we make sure the current event is committed before invoking those
      triggers.  To do that, we split the trigger invocation in two - the
      first part (event_triggers_call()) checks the filter using the current
      trace record; if a command has the post_trigger flag set, it sets a
      bit for itself in the return value, otherwise it directly invoks the
      trigger.  Once all commands have been either invoked or set their
      return flag, event_triggers_call() returns.  The current record is
      then either committed or discarded; if any commands have deferred
      their triggers, those commands are finally invoked following the close
      of the current event by event_triggers_post_call().
      
      To simplify the above and make it more efficient, the TRIGGER_COND bit
      is introduced, which is set only if a soft-disabled trigger needs to
      use the log record for filter testing or needs to wait until the
      current log record is closed.
      
      The syscall event invocation code is also changed in analogous ways.
      
      Because event triggers need to be able to create and free filters,
      this also adds a couple external wrappers for the existing
      create_filter and free_filter functions, which are too generic to be
      made extern functions themselves.
      
      Link: http://lkml.kernel.org/r/7164930759d8719ef460357f143d995406e4eead.1382622043.git.tom.zanussi@linux.intel.comSigned-off-by: default avatarTom Zanussi <tom.zanussi@linux.intel.com>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      bac5fb97
    • Steven Rostedt (Red Hat)'s avatar
      tracing: Move ftrace_event_file() out of DYNAMIC_FTRACE ifdef · 2875a08b
      Steven Rostedt (Red Hat) authored
      Now that event triggers use ftrace_event_file(), it needs to be outside
      the #ifdef CONFIG_DYNAMIC_FTRACE, as it can now be used when that is
      not defined.
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      2875a08b
    • Tom Zanussi's avatar
      tracing: Add 'enable_event' and 'disable_event' event trigger commands · 7862ad18
      Tom Zanussi authored
      Add 'enable_event' and 'disable_event' event_command commands.
      
      enable_event and disable_event event triggers are added by the user
      via these commands in a similar way and using practically the same
      syntax as the analagous 'enable_event' and 'disable_event' ftrace
      function commands, but instead of writing to the set_ftrace_filter
      file, the enable_event and disable_event triggers are written to the
      per-event 'trigger' files:
      
          echo 'enable_event:system:event' > .../othersys/otherevent/trigger
          echo 'disable_event:system:event' > .../othersys/otherevent/trigger
      
      The above commands will enable or disable the 'system:event' trace
      events whenever the othersys:otherevent events are hit.
      
      This also adds a 'count' version that limits the number of times the
      command will be invoked:
      
          echo 'enable_event:system:event:N' > .../othersys/otherevent/trigger
          echo 'disable_event:system:event:N' > .../othersys/otherevent/trigger
      
      Where N is the number of times the command will be invoked.
      
      The above commands will will enable or disable the 'system:event'
      trace events whenever the othersys:otherevent events are hit, but only
      N times.
      
      This also makes the find_event_file() helper function extern, since
      it's useful to use from other places, such as the event triggers code,
      so make it accessible.
      
      Link: http://lkml.kernel.org/r/f825f3048c3f6b026ee37ae5825f9fc373451828.1382622043.git.tom.zanussi@linux.intel.comSigned-off-by: default avatarTom Zanussi <tom.zanussi@linux.intel.com>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      7862ad18
    • Tom Zanussi's avatar
      tracing: Add 'stacktrace' event trigger command · f21ecbb3
      Tom Zanussi authored
      Add 'stacktrace' event_command.  stacktrace event triggers are added
      by the user via this command in a similar way and using practically
      the same syntax as the analogous 'stacktrace' ftrace function command,
      but instead of writing to the set_ftrace_filter file, the stacktrace
      event trigger is written to the per-event 'trigger' files:
      
          echo 'stacktrace' > .../tracing/events/somesys/someevent/trigger
      
      The above command will turn on stacktraces for someevent i.e. whenever
      someevent is hit, a stacktrace will be logged.
      
      This also adds a 'count' version that limits the number of times the
      command will be invoked:
      
          echo 'stacktrace:N' > .../tracing/events/somesys/someevent/trigger
      
      Where N is the number of times the command will be invoked.
      
      The above command will log N stacktraces for someevent i.e. whenever
      someevent is hit N times, a stacktrace will be logged.
      
      Link: http://lkml.kernel.org/r/0c30c008a0828c660aa0e1bbd3255cf179ed5c30.1382622043.git.tom.zanussi@linux.intel.comSigned-off-by: default avatarTom Zanussi <tom.zanussi@linux.intel.com>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      f21ecbb3
    • Tom Zanussi's avatar
      tracing: Add 'snapshot' event trigger command · 93e31ffb
      Tom Zanussi authored
      Add 'snapshot' event_command.  snapshot event triggers are added by
      the user via this command in a similar way and using practically the
      same syntax as the analogous 'snapshot' ftrace function command, but
      instead of writing to the set_ftrace_filter file, the snapshot event
      trigger is written to the per-event 'trigger' files:
      
          echo 'snapshot' > .../somesys/someevent/trigger
      
      The above command will turn on snapshots for someevent i.e. whenever
      someevent is hit, a snapshot will be done.
      
      This also adds a 'count' version that limits the number of times the
      command will be invoked:
      
          echo 'snapshot:N' > .../somesys/someevent/trigger
      
      Where N is the number of times the command will be invoked.
      
      The above command will snapshot N times for someevent i.e. whenever
      someevent is hit N times, a snapshot will be done.
      
      Also adds a new tracing_alloc_snapshot() function - the existing
      tracing_snapshot_alloc() function is a special version of
      tracing_snapshot() that also does the snapshot allocation - the
      snapshot triggers would like to be able to do just the allocation but
      not take a snapshot; the existing tracing_snapshot_alloc() in turn now
      also calls tracing_alloc_snapshot() underneath to do that allocation.
      
      Link: http://lkml.kernel.org/r/c9524dd07ce01f9dcbd59011290e0a8d5b47d7ad.1382622043.git.tom.zanussi@linux.intel.comSigned-off-by: default avatarTom Zanussi <tom.zanussi@linux.intel.com>
      [ fix up from kbuild test robot <fengguang.wu@intel.com report ]
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      93e31ffb
  7. 20 Dec, 2013 2 commits
    • Tom Zanussi's avatar
      tracing: Add 'traceon' and 'traceoff' event trigger commands · 2a2df321
      Tom Zanussi authored
      Add 'traceon' and 'traceoff' event_command commands.  traceon and
      traceoff event triggers are added by the user via these commands in a
      similar way and using practically the same syntax as the analagous
      'traceon' and 'traceoff' ftrace function commands, but instead of
      writing to the set_ftrace_filter file, the traceon and traceoff
      triggers are written to the per-event 'trigger' files:
      
          echo 'traceon' > .../tracing/events/somesys/someevent/trigger
          echo 'traceoff' > .../tracing/events/somesys/someevent/trigger
      
      The above command will turn tracing on or off whenever someevent is
      hit.
      
      This also adds a 'count' version that limits the number of times the
      command will be invoked:
      
          echo 'traceon:N' > .../tracing/events/somesys/someevent/trigger
          echo 'traceoff:N' > .../tracing/events/somesys/someevent/trigger
      
      Where N is the number of times the command will be invoked.
      
      The above commands will will turn tracing on or off whenever someevent
      is hit, but only N times.
      
      Some common register/unregister_trigger() implementations of the
      event_command reg()/unreg() callbacks are also provided, which add and
      remove trigger instances to the per-event list of triggers, and
      arm/disarm them as appropriate.  event_trigger_callback() is a
      general-purpose event_command func() implementation that orchestrates
      command parsing and registration for most normal commands.
      
      Most event commands will use these, but some will override and
      possibly reuse them.
      
      The event_trigger_init(), event_trigger_free(), and
      event_trigger_print() functions are meant to be common implementations
      of the event_trigger_ops init(), free(), and print() ops,
      respectively.
      
      Most trigger_ops implementations will use these, but some will
      override and possibly reuse them.
      
      Link: http://lkml.kernel.org/r/00a52816703b98d2072947478dd6e2d70cde5197.1382622043.git.tom.zanussi@linux.intel.comSigned-off-by: default avatarTom Zanussi <tom.zanussi@linux.intel.com>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      2a2df321
    • Tom Zanussi's avatar
      tracing: Add basic event trigger framework · 85f2b082
      Tom Zanussi authored
      Add a 'trigger' file for each trace event, enabling 'trace event
      triggers' to be set for trace events.
      
      'trace event triggers' are patterned after the existing 'ftrace
      function triggers' implementation except that triggers are written to
      per-event 'trigger' files instead of to a single file such as the
      'set_ftrace_filter' used for ftrace function triggers.
      
      The implementation is meant to be entirely separate from ftrace
      function triggers, in order to keep the respective implementations
      relatively simple and to allow them to diverge.
      
      The event trigger functionality is built on top of SOFT_DISABLE
      functionality.  It adds a TRIGGER_MODE bit to the ftrace_event_file
      flags which is checked when any trace event fires.  Triggers set for a
      particular event need to be checked regardless of whether that event
      is actually enabled or not - getting an event to fire even if it's not
      enabled is what's already implemented by SOFT_DISABLE mode, so trigger
      mode directly reuses that.  Event trigger essentially inherit the soft
      disable logic in __ftrace_event_enable_disable() while adding a bit of
      logic and trigger reference counting via tm_ref on top of that in a
      new trace_event_trigger_enable_disable() function.  Because the base
      __ftrace_event_enable_disable() code now needs to be invoked from
      outside trace_events.c, a wrapper is also added for those usages.
      
      The triggers for an event are actually invoked via a new function,
      event_triggers_call(), and code is also added to invoke them for
      ftrace_raw_event calls as well as syscall events.
      
      The main part of the patch creates a new trace_events_trigger.c file
      to contain the trace event triggers implementation.
      
      The standard open, read, and release file operations are implemented
      here.
      
      The open() implementation sets up for the various open modes of the
      'trigger' file.  It creates and attaches the trigger iterator and sets
      up the command parser.  If opened for reading set up the trigger
      seq_ops.
      
      The read() implementation parses the event trigger written to the
      'trigger' file, looks up the trigger command, and passes it along to
      that event_command's func() implementation for command-specific
      processing.
      
      The release() implementation does whatever cleanup is needed to
      release the 'trigger' file, like releasing the parser and trigger
      iterator, etc.
      
      A couple of functions for event command registration and
      unregistration are added, along with a list to add them to and a mutex
      to protect them, as well as an (initially empty) registration function
      to add the set of commands that will be added by future commits, and
      call to it from the trace event initialization code.
      
      also added are a couple trigger-specific data structures needed for
      these implementations such as a trigger iterator and a struct for
      trigger-specific data.
      
      A couple structs consisting mostly of function meant to be implemented
      in command-specific ways, event_command and event_trigger_ops, are
      used by the generic event trigger command implementations.  They're
      being put into trace.h alongside the other trace_event data structures
      and functions, in the expectation that they'll be needed in several
      trace_event-related files such as trace_events_trigger.c and
      trace_events.c.
      
      The event_command.func() function is meant to be called by the trigger
      parsing code in order to add a trigger instance to the corresponding
      event.  It essentially coordinates adding a live trigger instance to
      the event, and arming the triggering the event.
      
      Every event_command func() implementation essentially does the
      same thing for any command:
      
         - choose ops - use the value of param to choose either a number or
           count version of event_trigger_ops specific to the command
         - do the register or unregister of those ops
         - associate a filter, if specified, with the triggering event
      
      The reg() and unreg() ops allow command-specific implementations for
      event_trigger_op registration and unregistration, and the
      get_trigger_ops() op allows command-specific event_trigger_ops
      selection to be parameterized.  When a trigger instance is added, the
      reg() op essentially adds that trigger to the triggering event and
      arms it, while unreg() does the opposite.  The set_filter() function
      is used to associate a filter with the trigger - if the command
      doesn't specify a set_filter() implementation, the command will ignore
      filters.
      
      Each command has an associated trigger_type, which serves double duty,
      both as a unique identifier for the command as well as a value that
      can be used for setting a trigger mode bit during trigger invocation.
      
      The signature of func() adds a pointer to the event_command struct,
      used to invoke those functions, along with a command_data param that
      can be passed to the reg/unreg functions.  This allows func()
      implementations to use command-specific blobs and supports code
      re-use.
      
      The event_trigger_ops.func() command corrsponds to the trigger 'probe'
      function that gets called when the triggering event is actually
      invoked.  The other functions are used to list the trigger when
      needed, along with a couple mundane book-keeping functions.
      
      This also moves event_file_data() into trace.h so it can be used
      outside of trace_events.c.
      
      Link: http://lkml.kernel.org/r/316d95061accdee070aac8e5750afba0192fa5b9.1382622043.git.tom.zanussi@linux.intel.comSigned-off-by: default avatarTom Zanussi <tom.zanussi@linux.intel.com>
      Idea-by: default avatarSteve Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      85f2b082
  8. 15 Dec, 2013 5 commits
    • Linus Torvalds's avatar
      Linux 3.13-rc4 · 319e2e3f
      Linus Torvalds authored
      319e2e3f
    • Matias Bjorling's avatar
      null_blk: mem garbage on NUMA systems during init · 57053d8c
      Matias Bjorling authored
      For NUMA systems, initializing the blk-mq layer and using per node hctx.
      We initialize submit queues to 1, while blk-mq nr_hw_queues is
      initialized to the number of NUMA nodes.
      
      This makes the null_init_hctx function overwrite memory outside of what
      it allocated.  In my case it lead to writing garbage into struct
      request_queue's mq_map.
      Signed-off-by: default avatarMatias Bjorling <m@bjorling.me>
      Cc: Jens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      57053d8c
    • Sergey Senozhatsky's avatar
      radeon_pm: fix oops in hwmon_attributes_visible() and radeon_hwmon_show_temp_thresh() · e4158f1b
      Sergey Senozhatsky authored
      Since commit ec39f64b ("drm/radeon/dpm: Convert to use
      devm_hwmon_register_with_groups") radeon_hwmon_init() is using
      hwmon_device_register_with_groups(), which sets `rdev' as a device
      private driver_data, while hwmon_attributes_visible() and
      radeon_hwmon_show_temp_thresh() are still waiting for `drm_device'.
      
      Fix them by using dev_get_drvdata(), in order to avoid this oops:
      
        BUG: unable to handle kernel paging request at 0000000000001e28
        IP: [<ffffffffa02ae8b4>] hwmon_attributes_visible+0x18/0x3d [radeon]
        PGD 15057e067 PUD 151a8e067 PMD 0
        Oops: 0000 [#1] PREEMPT SMP
        Call Trace:
          internal_create_group+0x114/0x1d9
          sysfs_create_group+0xe/0x10
          sysfs_create_groups+0x22/0x5f
          device_add+0x34f/0x501
          device_register+0x15/0x18
          hwmon_device_register_with_groups+0xb5/0xed
          radeon_hwmon_init+0x56/0x7c [radeon]
          radeon_pm_init+0x134/0x7e5 [radeon]
          radeon_modeset_init+0x75f/0x8ed [radeon]
          radeon_driver_load_kms+0xc6/0x187 [radeon]
          drm_dev_register+0xf9/0x1b4 [drm]
          drm_get_pci_dev+0x98/0x129 [drm]
          radeon_pci_probe+0xa3/0xac [radeon]
          pci_device_probe+0x6e/0xcf
          driver_probe_device+0x98/0x1c4
          __driver_attach+0x5c/0x7e
          bus_for_each_dev+0x7b/0x85
          driver_attach+0x19/0x1b
          bus_add_driver+0x104/0x1ce
          driver_register+0x89/0xc5
          __pci_register_driver+0x58/0x5b
          drm_pci_init+0x86/0xea [drm]
          radeon_init+0x97/0x1000 [radeon]
          do_one_initcall+0x7f/0x117
          load_module+0x1583/0x1bb4
          SyS_init_module+0xa0/0xaf
      Signed-off-by: default avatarSergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Alexander Deucher <Alexander.Deucher@amd.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      e4158f1b
    • Linus Torvalds's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net · 4a251dd2
      Linus Torvalds authored
      Pull networking fixes from David Miller:
      
       1) Revert CHECKSUM_COMPLETE optimization in pskb_trim_rcsum(), I can't
          figure out why it breaks things.
      
       2) Fix comparison in netfilter ipset's hash_netnet4_data_equal(), it
          was basically doing "x == x", from Dave Jones.
      
       3) Freescale FEC driver was DMA mapping the wrong number of bytes, from
          Sebastian Siewior.
      
       4) Blackhole and prohibit routes in ipv6 were not doing the right thing
          because their ->input and ->output methods were not being assigned
          correctly.  Now they behave properly like their ipv4 counterparts.
          From Kamala R.
      
       5) Several drivers advertise the NETIF_F_FRAGLIST capability, but
          really do not support this feature and will send garbage packets if
          fed fraglist SKBs.  From Eric Dumazet.
      
       6) Fix long standing user triggerable BUG_ON over loopback in RDS
          protocol stack, from Venkat Venkatsubra.
      
       7) Several not so common code paths can potentially try to invoke
          packet scheduler actions that might be NULL without checking.  Shore
          things up by either 1) defining a method as mandatory and erroring
          on registration if that method is NULL 2) defininig a method as
          optional and the registration function hooks up a default
          implementation when NULL is seen.  From Jamal Hadi Salim.
      
       8) Fix fragment detection in xen-natback driver, from Paul Durrant.
      
       9) Kill dangling enter_memory_pressure method in cg_proto ops, from
          Eric W Biederman.
      
      10) SKBs that traverse namespaces should have their local_df cleared,
          from Hannes Frederic Sowa.
      
      11) IOCB file position is not being updated by macvtap_aio_read() and
          tun_chr_aio_read().  From Zhi Yong Wu.
      
      12) Don't free virtio_net netdev before releasing all of the NAPI
          instances.  From Andrey Vagin.
      
      13) Procfs entry leak in xt_hashlimit, from Sergey Popovich.
      
      14) IPv6 routes that are no cached routes should not count against the
          garbage collection limits.  We had this almost right, but were
          missing handling addrconf generated routes properly.  From Hannes
          Frederic Sowa.
      
      15) fib{4,6}_rule_suppress() have to consider potentially seeing NULL
          route info when they are called, from Stefan Tomanek.
      
      16) TUN and MACVTAP have had truncated packet signalling for some time,
          fix from Jason Wang.
      
      17) Fix use after frrr in __udp4_lib_rcv(), from Eric Dumazet.
      
      18) xen-netback does not interpret the NAPI budget properly for TX work,
          fix from Paul Durrant.
      
      * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (132 commits)
        igb: Fix for issue where values could be too high for udelay function.
        i40e: fix null dereference
        xen-netback: fix gso_prefix check
        net: make neigh_priv_len in struct net_device 16bit instead of 8bit
        drivers: net: cpsw: fix for cpsw crash when build as modules
        xen-netback: napi: don't prematurely request a tx event
        xen-netback: napi: fix abuse of budget
        sch_tbf: use do_div() for 64-bit divide
        udp: ipv4: must add synchronization in udp_sk_rx_dst_set()
        net:fec: remove duplicate lines in comment about errata ERR006358
        Revert "8390 : Replace ei_debug with msg_enable/NETIF_MSG_* feature"
        8390 : Replace ei_debug with msg_enable/NETIF_MSG_* feature
        xen-netback: make sure skb linear area covers checksum field
        net: smc91x: Fix device tree based configuration so it's usable
        udp: ipv4: fix potential use after free in udp_v4_early_demux()
        macvtap: signal truncated packets
        tun: unbreak truncated packet signalling
        net: sched: htb: fix the calculation of quantum
        net: sched: tbf: fix the calculation of max_size
        micrel: add support for KSZ8041RNLI
        ...
      4a251dd2
    • Linus Torvalds's avatar
      Merge branch 'x86/urgent' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 908bfda7
      Linus Torvalds authored
      Pull x86 fixes from Peter Anvin:
       "This is a pretty small batch:
      
        The biggest single change is to stop using EFI time services on 32-bit
        platforms.  This matches our current behavior on 64-bit platforms as
        we already had ruled them out there as being too unreliable.  Turns
        out that affects 32-bit platforms, too.
      
        One NULL pointer fix for SGI UV.
      
        Two minor build fixes, one of which only affects icc and the other
        which affects icc and future versions or nonstandard default settings
        of gcc"
      
      * 'x86/urgent' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        x86, efi: Don't use (U)EFI time services on 32 bit
        x86, build, icc: Remove uninitialized_var() from compiler-intel.h
        x86/UV: Fix NULL pointer dereference in uv_flush_tlb_others() if the 'nobau' boot option is used
        x86, build: Pass in additional -mno-mmx, -mno-sse options
      908bfda7