1. 05 Sep, 2018 1 commit
  2. 10 Dec, 2017 1 commit
  3. 08 Jul, 2017 3 commits
  4. 27 May, 2017 1 commit
  5. 26 May, 2017 1 commit
    • Thomas Gleixner's avatar
      kprobes: Cure hotplug lock ordering issues · 2d1e38f5
      Thomas Gleixner authored
      Converting the cpu hotplug locking to a percpu rwsem unearthed hidden lock
      ordering problems.
      
      There is a wide range of locks involved in this: kprobe_mutex,
      jump_label_mutex, ftrace_lock, text_mutex, event_mutex, module_mutex,
      func_hash->regex_lock and a gazillion of lock order permutations with
      nested get_online_cpus() calls.
      
      Some of those permutations are potential deadlocks even with the current
      nesting hotplug locking scheme, but they can't be discovered by lockdep.
      
      The conversion of the hotplug locking to a percpu rwsem requires to prevent
      nested locking, so it's required to take the hotplug rwsem early in the
      call chain and establish a proper lock order.
      
      After quite some analysis and going down the wrong road severa times the
      following lock order has been chosen:
      
      kprobe_mutex -> cpus_rwsem -> jump_label_mutex -> text_mutex
      
      For kprobes which hook on an ftrace function trace point, it's required to
      drop cpus_rwsem before calling into the ftrace code to avoid a deadlock on
      the func_hash->regex_lock.
      
      [ Steven: Ftrace interaction fixes ]
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Acked-by: default avatarIngo Molnar <mingo@kernel.org>
      Acked-by: default avatarMasami Hiramatsu <mhiramat@kernel.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Sebastian Siewior <bigeasy@linutronix.de>
      Link: http://lkml.kernel.org/r/20170524081549.104864779@linutronix.de
      2d1e38f5
  6. 18 May, 2017 2 commits
  7. 20 Apr, 2017 3 commits
  8. 15 Mar, 2017 1 commit
    • Naveen N. Rao's avatar
      trace/kprobes: Fix check for kretprobe offset within function entry · 1d585e70
      Naveen N. Rao authored
      perf specifies an offset from _text and since this offset is fed
      directly into the arch-specific helper, kprobes tracer rejects
      installation of kretprobes through perf. Fix this by looking up the
      actual offset from a function for the specified sym+offset.
      
      Refactor and reuse existing routines to limit code duplication -- we
      repurpose kprobe_addr() for determining final kprobe address and we
      split out the function entry offset determination into a separate
      generic helper.
      
      Before patch:
      
        naveen@ubuntu:~/linux/tools/perf$ sudo ./perf probe -v do_open%return
        probe-definition(0): do_open%return
        symbol:do_open file:(null) line:0 offset:0 return:1 lazy:(null)
        0 arguments
        Looking at the vmlinux_path (8 entries long)
        Using /boot/vmlinux for symbols
        Open Debuginfo file: /boot/vmlinux
        Try to find probe point from debuginfo.
        Matched function: do_open [2d0c7ff]
        Probe point found: do_open+0
        Matched function: do_open [35d76dc]
        found inline addr: 0xc0000000004ba9c4
        Failed to find "do_open%return",
         because do_open is an inlined function and has no return point.
        An error occurred in debuginfo analysis (-22).
        Trying to use symbols.
        Opening /sys/kernel/debug/tracing//README write=0
        Opening /sys/kernel/debug/tracing//kprobe_events write=1
        Writing event: r:probe/do_open _text+4469776
        Failed to write event: Invalid argument
          Error: Failed to add events. Reason: Invalid argument (Code: -22)
        naveen@ubuntu:~/linux/tools/perf$ dmesg | tail
        <snip>
        [   33.568656] Given offset is not valid for return probe.
      
      After patch:
      
        naveen@ubuntu:~/linux/tools/perf$ sudo ./perf probe -v do_open%return
        probe-definition(0): do_open%return
        symbol:do_open file:(null) line:0 offset:0 return:1 lazy:(null)
        0 arguments
        Looking at the vmlinux_path (8 entries long)
        Using /boot/vmlinux for symbols
        Open Debuginfo file: /boot/vmlinux
        Try to find probe point from debuginfo.
        Matched function: do_open [2d0c7d6]
        Probe point found: do_open+0
        Matched function: do_open [35d76b3]
        found inline addr: 0xc0000000004ba9e4
        Failed to find "do_open%return",
         because do_open is an inlined function and has no return point.
        An error occurred in debuginfo analysis (-22).
        Trying to use symbols.
        Opening /sys/kernel/debug/tracing//README write=0
        Opening /sys/kernel/debug/tracing//kprobe_events write=1
        Writing event: r:probe/do_open _text+4469808
        Writing event: r:probe/do_open_1 _text+4956344
        Added new events:
          probe:do_open        (on do_open%return)
          probe:do_open_1      (on do_open%return)
      
        You can now use it in all perf tools, such as:
      
      	  perf record -e probe:do_open_1 -aR sleep 1
      
        naveen@ubuntu:~/linux/tools/perf$ sudo cat /sys/kernel/debug/kprobes/list
        c000000000041370  k  kretprobe_trampoline+0x0    [OPTIMIZED]
        c0000000004ba0b8  r  do_open+0x8    [DISABLED]
        c000000000443430  r  do_open+0x0    [DISABLED]
      Signed-off-by: default avatarNaveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
      Acked-by: default avatarMasami Hiramatsu <mhiramat@kernel.org>
      Cc: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: linuxppc-dev@lists.ozlabs.org
      Link: http://lkml.kernel.org/r/d8cd1ef420ec22e3643ac332fdabcffc77319a42.1488961018.git.naveen.n.rao@linux.vnet.ibm.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      1d585e70
  9. 14 Mar, 2017 1 commit
  10. 03 Mar, 2017 1 commit
  11. 10 Feb, 2017 1 commit
  12. 14 Jan, 2017 1 commit
    • Masami Hiramatsu's avatar
      kprobes, extable: Identify kprobes trampolines as kernel text area · 5b485629
      Masami Hiramatsu authored
      Improve __kernel_text_address()/kernel_text_address() to return
      true if the given address is on a kprobe's instruction slot
      trampoline.
      
      This can help stacktraces to determine the address is on a
      text area or not.
      
      To implement this atomically in is_kprobe_*_slot(), also change
      the insn_cache page list to an RCU list.
      
      This changes timings a bit (it delays page freeing to the RCU garbage
      collection phase), but none of that is in the hot path.
      
      Note: this change can add small overhead to stack unwinders because
      it adds 2 additional checks to __kernel_text_address(). However, the
      impact should be very small, because kprobe_insn_pages list has 1 entry
      per 256 probes(on x86, on arm/arm64 it will be 1024 probes),
      and kprobe_optinsn_pages has 1 entry per 32 probes(on x86).
      In most use cases, the number of kprobe events may be less
      than 20, which means that is_kprobe_*_slot() will check just one entry.
      Tested-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Signed-off-by: default avatarMasami Hiramatsu <mhiramat@kernel.org>
      Acked-by: default avatarPeter Zijlstra <peterz@infradead.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andrey Konovalov <andreyknvl@google.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/148388747896.6869.6354262871751682264.stgit@devbox
      [ Improved the changelog and coding style. ]
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      5b485629
  13. 24 Dec, 2016 1 commit
  14. 11 Oct, 2016 1 commit
  15. 04 Aug, 2015 1 commit
  16. 14 Feb, 2015 2 commits
  17. 20 Jan, 2015 1 commit
    • Rusty Russell's avatar
      module: remove mod arg from module_free, rename module_memfree(). · be1f221c
      Rusty Russell authored
      Nothing needs the module pointer any more, and the next patch will
      call it from RCU, where the module itself might no longer exist.
      Removing the arg is the safest approach.
      
      This just codifies the use of the module_alloc/module_free pattern
      which ftrace and bpf use.
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Cc: Mikael Starvik <starvik@axis.com>
      Cc: Jesper Nilsson <jesper.nilsson@axis.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Ley Foon Tan <lftan@altera.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Chris Metcalf <cmetcalf@ezchip.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: x86@kernel.org
      Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      Cc: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
      Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: linux-cris-kernel@axis.com
      Cc: linux-kernel@vger.kernel.org
      Cc: linux-mips@linux-mips.org
      Cc: nios2-dev@lists.rocketboards.org
      Cc: linuxppc-dev@lists.ozlabs.org
      Cc: sparclinux@vger.kernel.org
      Cc: netdev@vger.kernel.org
      be1f221c
  18. 13 Jan, 2015 1 commit
  19. 21 Nov, 2014 1 commit
  20. 27 Oct, 2014 1 commit
  21. 08 Aug, 2014 1 commit
  22. 18 Jul, 2014 1 commit
  23. 24 Apr, 2014 5 commits
    • Masami Hiramatsu's avatar
      kprobes: Show blacklist entries via debugfs · 63724740
      Masami Hiramatsu authored
      Show blacklist entries (function names with the address
      range) via /sys/kernel/debug/kprobes/blacklist.
      
      Note that at this point the blacklist supports only
      in vmlinux, not module. So the list is fixed and
      not updated.
      Signed-off-by: default avatarMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      Cc: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
      Cc: David S. Miller <davem@davemloft.net>
      Link: http://lkml.kernel.org/r/20140417081849.26341.11609.stgit@ltc230.yrl.intra.hitachi.co.jpSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      63724740
    • Masami Hiramatsu's avatar
      kprobes: Use NOKPROBE_SYMBOL macro instead of __kprobes · 820aede0
      Masami Hiramatsu authored
      Use NOKPROBE_SYMBOL macro to protect functions from
      kprobes instead of __kprobes annotation.
      Signed-off-by: default avatarMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Reviewed-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      Cc: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
      Cc: David S. Miller <davem@davemloft.net>
      Link: http://lkml.kernel.org/r/20140417081821.26341.40362.stgit@ltc230.yrl.intra.hitachi.co.jpSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      820aede0
    • Masami Hiramatsu's avatar
      kprobes: Allow probe on some kprobe functions · 55479f64
      Masami Hiramatsu authored
      There is no need to prohibit probing on the functions
      used for preparation, registeration, optimization,
      controll etc. Those are safely probed because those are
      not invoked from breakpoint/fault/debug handlers,
      there is no chance to cause recursive exceptions.
      
      Following functions are now removed from the kprobes blacklist:
      
      	add_new_kprobe
      	aggr_kprobe_disabled
      	alloc_aggr_kprobe
      	alloc_aggr_kprobe
      	arm_all_kprobes
      	__arm_kprobe
      	arm_kprobe
      	arm_kprobe_ftrace
      	check_kprobe_address_safe
      	collect_garbage_slots
      	collect_garbage_slots
      	collect_one_slot
      	debugfs_kprobe_init
      	__disable_kprobe
      	disable_kprobe
      	disarm_all_kprobes
      	__disarm_kprobe
      	disarm_kprobe
      	disarm_kprobe_ftrace
      	do_free_cleaned_kprobes
      	do_optimize_kprobes
      	do_unoptimize_kprobes
      	enable_kprobe
      	force_unoptimize_kprobe
      	free_aggr_kprobe
      	free_aggr_kprobe
      	__free_insn_slot
      	__get_insn_slot
      	get_optimized_kprobe
      	__get_valid_kprobe
      	init_aggr_kprobe
      	init_aggr_kprobe
      	in_nokprobe_functions
      	kick_kprobe_optimizer
      	kill_kprobe
      	kill_optimized_kprobe
      	kprobe_addr
      	kprobe_optimizer
      	kprobe_queued
      	kprobe_seq_next
      	kprobe_seq_start
      	kprobe_seq_stop
      	kprobes_module_callback
      	kprobes_open
      	optimize_all_kprobes
      	optimize_kprobe
      	prepare_kprobe
      	prepare_optimized_kprobe
      	register_aggr_kprobe
      	register_jprobe
      	register_jprobes
      	register_kprobe
      	register_kprobes
      	register_kretprobe
      	register_kretprobe
      	register_kretprobes
      	register_kretprobes
      	report_probe
      	show_kprobe_addr
      	try_to_optimize_kprobe
      	unoptimize_all_kprobes
      	unoptimize_kprobe
      	unregister_jprobe
      	unregister_jprobes
      	unregister_kprobe
      	__unregister_kprobe_bottom
      	unregister_kprobes
      	__unregister_kprobe_top
      	unregister_kretprobe
      	unregister_kretprobe
      	unregister_kretprobes
      	unregister_kretprobes
      	wait_for_kprobe_optimizer
      
      I tested those functions by putting kprobes on all
      instructions in the functions with the bash script
      I sent to LKML. See:
      
        https://lkml.org/lkml/2014/3/27/33Signed-off-by: default avatarMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Link: http://lkml.kernel.org/r/20140417081753.26341.57889.stgit@ltc230.yrl.intra.hitachi.co.jp
      Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      Cc: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: fche@redhat.com
      Cc: systemtap@sourceware.org
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      55479f64
    • Masami Hiramatsu's avatar
      kprobes: Introduce NOKPROBE_SYMBOL() macro to maintain kprobes blacklist · 376e2424
      Masami Hiramatsu authored
      Introduce NOKPROBE_SYMBOL() macro which builds a kprobes
      blacklist at kernel build time.
      
      The usage of this macro is similar to EXPORT_SYMBOL(),
      placed after the function definition:
      
        NOKPROBE_SYMBOL(function);
      
      Since this macro will inhibit inlining of static/inline
      functions, this patch also introduces a nokprobe_inline macro
      for static/inline functions. In this case, we must use
      NOKPROBE_SYMBOL() for the inline function caller.
      
      When CONFIG_KPROBES=y, the macro stores the given function
      address in the "_kprobe_blacklist" section.
      
      Since the data structures are not fully initialized by the
      macro (because there is no "size" information),  those
      are re-initialized at boot time by using kallsyms.
      Signed-off-by: default avatarMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Link: http://lkml.kernel.org/r/20140417081705.26341.96719.stgit@ltc230.yrl.intra.hitachi.co.jp
      Cc: Alok Kataria <akataria@vmware.com>
      Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Christopher Li <sparse@chrisli.org>
      Cc: Chris Wright <chrisw@sous-sol.org>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Jan-Simon Möller <dl9pf@gmx.de>
      Cc: Jeremy Fitzhardinge <jeremy@goop.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Randy Dunlap <rdunlap@infradead.org>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: linux-arch@vger.kernel.org
      Cc: linux-doc@vger.kernel.org
      Cc: linux-sparse@vger.kernel.org
      Cc: virtualization@lists.linux-foundation.org
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      376e2424
    • Masami Hiramatsu's avatar
      kprobes: Prohibit probing on .entry.text code · be8f2743
      Masami Hiramatsu authored
      .entry.text is a code area which is used for interrupt/syscall
      entries, which includes many sensitive code.
      Thus, it is better to prohibit probing on all of such code
      instead of a part of that.
      Since some symbols are already registered on kprobe blacklist,
      this also removes them from the blacklist.
      Signed-off-by: default avatarMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Reviewed-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      Cc: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Jan Kiszka <jan.kiszka@siemens.com>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Jonathan Lebon <jlebon@redhat.com>
      Cc: Seiji Aguchi <seiji.aguchi@hds.com>
      Link: http://lkml.kernel.org/r/20140417081658.26341.57354.stgit@ltc230.yrl.intra.hitachi.co.jpSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      be8f2743
  24. 13 Nov, 2013 1 commit
  25. 11 Sep, 2013 2 commits
    • Heiko Carstens's avatar
      kprobes: allow to specify custom allocator for insn caches · af96397d
      Heiko Carstens authored
      The current two insn slot caches both use module_alloc/module_free to
      allocate and free insn slot cache pages.
      
      For s390 this is not sufficient since there is the need to allocate insn
      slots that are either within the vmalloc module area or within dma memory.
      
      Therefore add a mechanism which allows to specify an own allocator for an
      own insn slot cache.
      Signed-off-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Acked-by: default avatarMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      af96397d
    • Heiko Carstens's avatar
      kprobes: unify insn caches · c802d64a
      Heiko Carstens authored
      The current kpropes insn caches allocate memory areas for insn slots
      with module_alloc().  The assumption is that the kernel image and module
      area are both within the same +/- 2GB memory area.
      
      This however is not true for s390 where the kernel image resides within
      the first 2GB (DMA memory area), but the module area is far away in the
      vmalloc area, usually somewhere close below the 4TB area.
      
      For new pc relative instructions s390 needs insn slots that are within
      +/- 2GB of each area.  That way we can patch displacements of
      pc-relative instructions within the insn slots just like x86 and
      powerpc.
      
      The module area works already with the normal insn slot allocator,
      however there is currently no way to get insn slots that are within the
      first 2GB on s390 (aka DMA area).
      
      Therefore this patch set modifies the kprobes insn slot cache code in
      order to allow to specify a custom allocator for the insn slot cache
      pages.  In addition architecure can now have private insn slot caches
      withhout the need to modify common code.
      
      Patch 1 unifies and simplifies the current insn and optinsn caches
              implementation. This is a preparation which allows to add more
              insn caches in a simple way.
      
      Patch 2 adds the possibility to specify a custom allocator.
      
      Patch 3 makes s390 use the new insn slot mechanisms and adds support for
              pc-relative instructions with long displacements.
      
      This patch (of 3):
      
      The two insn caches (insn, and optinsn) each have an own mutex and
      alloc/free functions (get_[opt]insn_slot() / free_[opt]insn_slot()).
      
      Since there is the need for yet another insn cache which satifies dma
      allocations on s390, unify and simplify the current implementation:
      
      - Move the per insn cache mutex into struct kprobe_insn_cache.
      - Move the alloc/free functions to kprobe.h so they are simply
        wrappers for the generic __get_insn_slot/__free_insn_slot functions.
        The implementation is done with a DEFINE_INSN_CACHE_OPS() macro
        which provides the alloc/free functions for each cache if needed.
      - move the struct kprobe_insn_cache to kprobe.h which allows to generate
        architecture specific insn slot caches outside of the core kprobes
        code.
      Signed-off-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      c802d64a
  26. 23 Jul, 2013 1 commit
    • Jiri Kosina's avatar
      kprobes/x86: Call out into INT3 handler directly instead of using notifier · 17f41571
      Jiri Kosina authored
      In fd4363ff ("x86: Introduce int3 (breakpoint)-based
      instruction patching"), the mechanism that was introduced for
      notifying alternatives code from int3 exception handler that and
      exception occured was die_notifier.
      
      This is however problematic, as early code might be using jump
      labels even before the notifier registration has been performed,
      which will then lead to an oops due to unhandled exception. One
      of such occurences has been encountered by Fengguang:
      
       int3: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
       Modules linked in:
       CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.11.0-rc1-01429-g04bf576 #8
       task: ffff88000da1b040 ti: ffff88000da1c000 task.ti: ffff88000da1c000
       RIP: 0010:[<ffffffff811098cc>]  [<ffffffff811098cc>] ttwu_do_wakeup+0x28/0x225
       RSP: 0000:ffff88000dd03f10  EFLAGS: 00000006
       RAX: 0000000000000000 RBX: ffff88000dd12940 RCX: ffffffff81769c40
       RDX: 0000000000000002 RSI: 0000000000000000 RDI: 0000000000000001
       RBP: ffff88000dd03f28 R08: ffffffff8176a8c0 R09: 0000000000000002
       R10: ffffffff810ff484 R11: ffff88000dd129e8 R12: ffff88000dbc90c0
       R13: ffff88000dbc90c0 R14: ffff88000da1dfd8 R15: ffff88000da1dfd8
       FS:  0000000000000000(0000) GS:ffff88000dd00000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
       CR2: 00000000ffffffff CR3: 0000000001c88000 CR4: 00000000000006e0
       Stack:
        ffff88000dd12940 ffff88000dbc90c0 ffff88000da1dfd8 ffff88000dd03f48
        ffffffff81109e2b ffff88000dd12940 0000000000000000 ffff88000dd03f68
        ffffffff81109e9e 0000000000000000 0000000000012940 ffff88000dd03f98
       Call Trace:
        <IRQ>
        [<ffffffff81109e2b>] ttwu_do_activate.constprop.56+0x6d/0x79
        [<ffffffff81109e9e>] sched_ttwu_pending+0x67/0x84
        [<ffffffff8110c845>] scheduler_ipi+0x15a/0x2b0
        [<ffffffff8104dfb4>] smp_reschedule_interrupt+0x38/0x41
        [<ffffffff8173bf5d>] reschedule_interrupt+0x6d/0x80
        <EOI>
        [<ffffffff810ff484>] ? __atomic_notifier_call_chain+0x5/0xc1
        [<ffffffff8105cc30>] ? native_safe_halt+0xd/0x16
        [<ffffffff81015f10>] default_idle+0x147/0x282
        [<ffffffff81017026>] arch_cpu_idle+0x3d/0x5d
        [<ffffffff81127d6a>] cpu_idle_loop+0x46d/0x5db
        [<ffffffff81127f5c>] cpu_startup_entry+0x84/0x84
        [<ffffffff8104f4f8>] start_secondary+0x3c8/0x3d5
        [...]
      
      Fix this by directly calling poke_int3_handler() from the int3
      exception handler (analogically to what ftrace has been doing
      already), instead of relying on notifier, registration of which
      might not have yet been finalized by the time of the first trap.
      Reported-and-tested-by: default avatarFengguang Wu <fengguang.wu@intel.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Acked-by: default avatarMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: H. Peter Anvin <hpa@linux.intel.com>
      Cc: Fengguang Wu <fengguang.wu@intel.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Link: http://lkml.kernel.org/r/alpine.LNX.2.00.1307231007490.14024@pobox.suse.czSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      17f41571
  27. 17 Jul, 2013 1 commit
  28. 03 Jul, 2013 1 commit
  29. 28 May, 2013 1 commit
    • Masami Hiramatsu's avatar
      kprobes: Fix to free gone and unused optprobes · 7b959fc5
      Masami Hiramatsu authored
      Fix to free gone and unused optprobes. This bug will
      cause a kernel panic if the user reuses the killed and
      unused probe.
      
      Reported at:
      
        http://sourceware.org/ml/systemtap/2013-q2/msg00142.html
      
      In the normal path, an optprobe on an init function is
      unregistered when a module goes live.
      
      unregister_kprobe(kp)
       -> __unregister_kprobe_top
         ->__disable_kprobe
           ->disarm_kprobe(ap == op)
             ->__disarm_kprobe
              ->unoptimize_kprobe : the op is queued
                                    on unoptimizing_list
      and do nothing in __unregister_kprobe_bottom
      
      After a while (usually wait 5 jiffies), kprobe_optimizer
      runs to unoptimize and free optprobe.
      
      kprobe_optimizer
       ->do_unoptimize_kprobes
         ->arch_unoptimize_kprobes : moved to free_list
       ->do_free_cleaned_kprobes
         ->hlist_del: the op is removed
         ->free_aggr_kprobe
           ->arch_remove_optimized_kprobe
           ->arch_remove_kprobe
           ->kfree: the op is freed
      
      Here, if kprobes_module_callback is called and the delayed
      unoptimizing probe is picked BEFORE kprobe_optimizer runs,
      
      kprobes_module_callback
       ->kill_kprobe
         ->kill_optimized_kprobe : dequeued from unoptimizing_list <=!!!
           ->arch_remove_optimized_kprobe
         ->arch_remove_kprobe
         (but op is not freed, and on the kprobe hash table)
      
      This doesn't happen if the probe unregistration is done AFTER
      kprobes_module_callback is called (because at that time the op
      is gone), and kprobe-tracer does it.
      
      To fix this bug, this patch changes kprobes_module_callback to
      enqueue the op to freeing_list at kill_optimized_kprobe only
      if the op is unused. The unused probes on freeing_list will
      be freed in do_free_cleaned_kprobes.
      
      Note that this calls arch_remove_*kprobe twice on the
      same probe. Thus those functions have to check the double free.
      Fortunately, most of arch codes already checked that except
      for mips. This will be fixed in the next patch.
      Signed-off-by: default avatarMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Timo Juhani Lindfors <timo.lindfors@iki.fi>
      Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      Cc: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
      Cc: Frank Ch. Eigler <fche@redhat.com>
      Cc: systemtap@sourceware.org
      Cc: yrl.pp-manager.tt@hitachi.com
      Cc: David S. Miller <davem@davemloft.net>
      Cc: "David S. Miller" <davem@davemloft.net>
      Link: http://lkml.kernel.org/r/20130522093409.9084.63554.stgit@mhiramat-M0-7522
      [ Minor edits. ]
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      7b959fc5