1. 03 2月, 2016 2 次提交
    • R
      module: wrapper for symbol name. · 2e7bac53
      Rusty Russell 提交于
      This trivial wrapper adds clarity and makes the following patch
      smaller.
      
      Cc: stable@kernel.org
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      2e7bac53
    • L
      modules: fix modparam async_probe request · 4355efbd
      Luis R. Rodriguez 提交于
      Commit f2411da7 ("driver-core: add driver module
      asynchronous probe support") added async probe support,
      in two forms:
      
        * in-kernel driver specification annotation
        * generic async_probe module parameter (modprobe foo async_probe)
      
      To support the generic kernel parameter parse_args() was
      extended via commit ecc86170 ("module: add extra
      argument for parse_params() callback") however commit
      failed to f2411da7 failed to add the required argument.
      
      This causes a crash then whenever async_probe generic
      module parameter is used. This was overlooked when the
      form in which in-kernel async probe support was reworked
      a bit... Fix this as originally intended.
      
      Cc: Hannes Reinecke <hare@suse.de>
      Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
      Cc: stable@vger.kernel.org (4.2+)
      Signed-off-by: NLuis R. Rodriguez <mcgrof@suse.com>
      Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> [minimized]
      4355efbd
  2. 08 1月, 2016 1 次提交
  3. 05 12月, 2015 4 次提交
    • M
      module: keep percpu symbols in module's symtab · e0224418
      Miroslav Benes 提交于
      Currently, percpu symbols from .data..percpu ELF section of a module are
      not copied over and stored in final symtab array of struct module.
      Consequently such symbol cannot be returned via kallsyms API (for
      example kallsyms_lookup_name). This can be especially confusing when the
      percpu symbol is exported. Only its __ksymtab et al. are present in its
      symtab.
      
      The culprit is in layout_and_allocate() function where SHF_ALLOC flag is
      dropped for .data..percpu section. There is in fact no need to copy the
      section to final struct module, because kernel module loader allocates
      extra percpu section by itself. Unfortunately only symbols from
      SHF_ALLOC sections are copied due to a check in is_core_symbol().
      
      The patch changes is_core_symbol() function to copy over also percpu
      symbols (their st_shndx points to .data..percpu ELF section). We do it
      only if CONFIG_KALLSYMS_ALL is set to be consistent with the rest of the
      function (ELF section is SHF_ALLOC but !SHF_EXECINSTR). Finally
      elf_type() returns type 'a' for a percpu symbol because its address is
      absolute.
      Signed-off-by: NMiroslav Benes <mbenes@suse.cz>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      e0224418
    • R
      module: clean up RO/NX handling. · 85c898db
      Rusty Russell 提交于
      Modules have three sections: text, rodata and writable data.  The code
      handled the case where these overlapped, however they never can:
      debug_align() ensures they are always page-aligned.
      
      This is why we got away with manually traversing the pages in
      set_all_modules_text_rw() without rounding.
      
      We create three helper functions: frob_text(), frob_rodata() and
      frob_writable_data().  We then call these explicitly at every point,
      so it's clear what we're doing.
      
      We also expose module_enable_ro() and module_disable_ro() for
      livepatch to use.
      Reviewed-by: NJosh Poimboeuf <jpoimboe@redhat.com>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      85c898db
    • R
      module: use a structure to encapsulate layout. · 7523e4dc
      Rusty Russell 提交于
      Makes it easier to handle init vs core cleanly, though the change is
      fairly invasive across random architectures.
      
      It simplifies the rbtree code immediately, however, while keeping the
      core data together in the same cachline (now iff the rbtree code is
      enabled).
      Acked-by: NPeter Zijlstra <peterz@infradead.org>
      Reviewed-by: NJosh Poimboeuf <jpoimboe@redhat.com>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      7523e4dc
    • J
      module: Use the same logic for setting and unsetting RO/NX · 20ef10c1
      Josh Poimboeuf 提交于
      When setting a module's RO and NX permissions, set_section_ro_nx() is
      used, but when clearing them, unset_module_{init,core}_ro_nx() are used.
      The unset functions don't have the same checks the set function has for
      partial page protections.  It's probably harmless, but it's still
      confusingly asymmetrical.
      
      Instead, use the same logic to do both.  Also add some new
      set_module_{init,core}_ro_nx() helper functions for more symmetry with
      the unset functions.
      Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      20ef10c1
  4. 24 8月, 2015 1 次提交
    • P
      module: Fix locking in symbol_put_addr() · 275d7d44
      Peter Zijlstra 提交于
      Poma (on the way to another bug) reported an assertion triggering:
      
        [<ffffffff81150529>] module_assert_mutex_or_preempt+0x49/0x90
        [<ffffffff81150822>] __module_address+0x32/0x150
        [<ffffffff81150956>] __module_text_address+0x16/0x70
        [<ffffffff81150f19>] symbol_put_addr+0x29/0x40
        [<ffffffffa04b77ad>] dvb_frontend_detach+0x7d/0x90 [dvb_core]
      
      Laura Abbott <labbott@redhat.com> produced a patch which lead us to
      inspect symbol_put_addr(). This function has a comment claiming it
      doesn't need to disable preemption around the module lookup
      because it holds a reference to the module it wants to find, which
      therefore cannot go away.
      
      This is wrong (and a false optimization too, preempt_disable() is really
      rather cheap, and I doubt any of this is on uber critical paths,
      otherwise it would've retained a pointer to the actual module anyway and
      avoided the second lookup).
      
      While its true that the module cannot go away while we hold a reference
      on it, the data structure we do the lookup in very much _CAN_ change
      while we do the lookup. Therefore fix the comment and add the
      required preempt_disable().
      Reported-by: Npoma <pomidorabelisima@gmail.com>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      Fixes: a6e6abd5 ("module: remove module_text_address()")
      Cc: stable@kernel.org
      275d7d44
  5. 29 7月, 2015 1 次提交
  6. 09 7月, 2015 1 次提交
  7. 28 6月, 2015 1 次提交
  8. 23 6月, 2015 1 次提交
    • D
      module: add per-module param_lock · b51d23e4
      Dan Streetman 提交于
      Add a "param_lock" mutex to each module, and update params.c to use
      the correct built-in or module mutex while locking kernel params.
      Remove the kparam_block_sysfs_r/w() macros, replace them with direct
      calls to kernel_param_[un]lock(module).
      
      The kernel param code currently uses a single mutex to protect
      modification of any and all kernel params.  While this generally works,
      there is one specific problem with it; a module callback function
      cannot safely load another module, i.e. with request_module() or even
      with indirect calls such as crypto_has_alg().  If the module to be
      loaded has any of its params configured (e.g. with a /etc/modprobe.d/*
      config file), then the attempt will result in a deadlock between the
      first module param callback waiting for modprobe, and modprobe trying to
      lock the single kernel param mutex to set the new module's param.
      
      This fixes that by using per-module mutexes, so that each individual module
      is protected against concurrent changes in its own kernel params, but is
      not blocked by changes to other module params.  All built-in modules
      continue to use the built-in mutex, since they will always be loaded at
      runtime and references (e.g. request_module(), crypto_has_alg()) to them
      will never cause load-time param changing.
      
      This also simplifies the interface used by modules to block sysfs access
      to their params; while there are currently functions to block and unblock
      sysfs param access which are split up by read and write and expect a single
      kernel param to be passed, their actual operation is identical and applies
      to all params, not just the one passed to them; they simply lock and unlock
      the global param mutex.  They are replaced with direct calls to
      kernel_param_[un]lock(THIS_MODULE), which locks THIS_MODULE's param_lock, or
      if the module is built-in, it locks the built-in mutex.
      Suggested-by: NRusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: NDan Streetman <ddstreet@ieee.org>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      b51d23e4
  9. 28 5月, 2015 8 次提交
    • L
      kernel/module.c: avoid ifdefs for sig_enforce declaration · 6727bb9c
      Luis R. Rodriguez 提交于
      There's no need to require an ifdef over the declaration
      of sig_enforce as IS_ENABLED() can be used. While at it,
      there's no harm in exposing this kernel parameter outside of
      CONFIG_MODULE_SIG as it'd be a no-op on non module sig
      kernels.
      
      Now, technically we should in theory be able to remove
      the #ifdef'ery over the declaration of the module parameter
      as we are also trusting the bool_enable_only code for
      CONFIG_MODULE_SIG kernels but for now remain paranoid
      and keep it.
      
      With time if no one can put a bullet through bool_enable_only
      and if there are no technical requirements over not exposing
      CONFIG_MODULE_SIG_FORCE with the measures in place by
      bool_enable_only we could remove this last ifdef.
      
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: linux-kernel@vger.kernel.org
      Cc: cocci@systeme.lip6.fr
      Signed-off-by: NLuis R. Rodriguez <mcgrof@suse.com>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      6727bb9c
    • L
      kernel/params.c: generalize bool_enable_only · d19f05d8
      Luis R. Rodriguez 提交于
      This takes out the bool_enable_only implementation from
      the module loading code and generalizes it so that others
      can make use of it.
      
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Jani Nikula <jani.nikula@intel.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: linux-kernel@vger.kernel.org
      Cc: cocci@systeme.lip6.fr
      Signed-off-by: NLuis R. Rodriguez <mcgrof@suse.com>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      d19f05d8
    • L
      kernel/module.c: use generic module param operaters for sig_enforce · 05f408dd
      Luis R. Rodriguez 提交于
      We're directly checking and modifying sig_enforce when needed instead
      of using the generic helpers. This prevents us from generalizing this
      helper so that others can use it. Use indirect helpers to allow us
      to generalize this code a bit and to make it a bit more clear what
      this is doing.
      
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Jani Nikula <jani.nikula@intel.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: linux-kernel@vger.kernel.org
      Cc: cocci@systeme.lip6.fr
      Signed-off-by: NLuis R. Rodriguez <mcgrof@suse.com>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      05f408dd
    • P
      module: Rework module_addr_{min,max} · 4f666546
      Peter Zijlstra 提交于
      __module_address() does an initial bound check before doing the
      {list/tree} iteration to find the actual module. The bound variables
      are nowhere near the mod_tree cacheline, in fact they're nowhere near
      one another.
      
      module_addr_min lives in .data while module_addr_max lives in .bss
      (smarty pants GCC thinks the explicit 0 assignment is a mistake).
      
      Rectify this by moving the two variables into a structure together
      with the latch_tree_root to guarantee they all share the same
      cacheline and avoid hitting two extra cachelines for the lookup.
      
      While reworking the bounds code, move the bound update from allocation
      to insertion time, this avoids updating the bounds for a few error
      paths.
      
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      4f666546
    • P
      module: Use __module_address() for module_address_lookup() · b7df4d1b
      Peter Zijlstra 提交于
      Use the generic __module_address() addr to struct module lookup
      instead of open coding it once more.
      
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      b7df4d1b
    • P
      module: Make the mod_tree stuff conditional on PERF_EVENTS || TRACING · 6c9692e2
      Peter Zijlstra 提交于
      Andrew worried about the overhead on small systems; only use the fancy
      code when either perf or tracing is enabled.
      
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Requested-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      6c9692e2
    • P
      module: Optimize __module_address() using a latched RB-tree · 93c2e105
      Peter Zijlstra 提交于
      Currently __module_address() is using a linear search through all
      modules in order to find the module corresponding to the provided
      address. With a lot of modules this can take a lot of time.
      
      One of the users of this is kernel_text_address() which is employed
      in many stack unwinders; which in turn are used by perf-callchain and
      ftrace (possibly from NMI context).
      
      So by optimizing __module_address() we optimize many stack unwinders
      which are used by both perf and tracing in performance sensitive code.
      
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      93c2e105
    • P
      module: Sanitize RCU usage and locking · 0be964be
      Peter Zijlstra 提交于
      Currently the RCU usage in module is an inconsistent mess of RCU and
      RCU-sched, this is broken for CONFIG_PREEMPT where synchronize_rcu()
      does not imply synchronize_sched().
      
      Most usage sites use preempt_{dis,en}able() which is RCU-sched, but
      (most of) the modification sites use synchronize_rcu(). With the
      exception of the module bug list, which actually uses RCU.
      
      Convert everything over to RCU-sched.
      
      Furthermore add lockdep asserts to all sites, because it's not at all
      clear to me the required locking is observed, esp. on exported
      functions.
      
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Acked-by: N"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      0be964be
  10. 27 5月, 2015 1 次提交
    • P
      module: Annotate module version magic · 926a59b1
      Peter Zijlstra 提交于
      Due to the new lockdep checks in the coming patch, we go:
      
      [    9.759380] ------------[ cut here ]------------
      [    9.759389] WARNING: CPU: 31 PID: 597 at ../kernel/module.c:216 each_symbol_section+0x121/0x130()
      [    9.759391] Modules linked in:
      [    9.759393] CPU: 31 PID: 597 Comm: modprobe Not tainted 4.0.0-rc1+ #65
      [    9.759393] Hardware name: Intel Corporation S2600GZ/S2600GZ, BIOS SE5C600.86B.02.02.0002.122320131210 12/23/2013
      [    9.759396]  ffffffff817d8676 ffff880424567ca8 ffffffff8157e98b 0000000000000001
      [    9.759398]  0000000000000000 ffff880424567ce8 ffffffff8105fbc7 ffff880424567cd8
      [    9.759400]  0000000000000000 ffffffff810ec160 ffff880424567d40 0000000000000000
      [    9.759400] Call Trace:
      [    9.759407]  [<ffffffff8157e98b>] dump_stack+0x4f/0x7b
      [    9.759410]  [<ffffffff8105fbc7>] warn_slowpath_common+0x97/0xe0
      [    9.759412]  [<ffffffff810ec160>] ? section_objs+0x60/0x60
      [    9.759414]  [<ffffffff8105fc2a>] warn_slowpath_null+0x1a/0x20
      [    9.759415]  [<ffffffff810ed9c1>] each_symbol_section+0x121/0x130
      [    9.759417]  [<ffffffff810eda01>] find_symbol+0x31/0x70
      [    9.759420]  [<ffffffff810ef5bf>] load_module+0x20f/0x2660
      [    9.759422]  [<ffffffff8104ef10>] ? __do_page_fault+0x190/0x4e0
      [    9.759426]  [<ffffffff815880ec>] ? retint_restore_args+0x13/0x13
      [    9.759427]  [<ffffffff815880ec>] ? retint_restore_args+0x13/0x13
      [    9.759433]  [<ffffffff810ae73d>] ? trace_hardirqs_on_caller+0x11d/0x1e0
      [    9.759437]  [<ffffffff812fcc0e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
      [    9.759439]  [<ffffffff815880ec>] ? retint_restore_args+0x13/0x13
      [    9.759441]  [<ffffffff810f1ade>] SyS_init_module+0xce/0x100
      [    9.759443]  [<ffffffff81587429>] system_call_fastpath+0x12/0x17
      [    9.759445] ---[ end trace 9294429076a9c644 ]---
      
      As per the comment this site should be fine, but lets wrap it in
      preempt_disable() anyhow to placate lockdep.
      
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Acked-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      926a59b1
  11. 20 5月, 2015 2 次提交
    • L
      driver-core: add driver module asynchronous probe support · f2411da7
      Luis R. Rodriguez 提交于
      Some init systems may wish to express the desire to have device drivers
      run their probe() code asynchronously. This implements support for this
      and allows userspace to request async probe as a preference through a
      generic shared device driver module parameter, async_probe.
      
      Implementation for async probe is supported through a module parameter
      given that since synchronous probe has been prevalent for years some
      userspace might exist which relies on the fact that the device driver
      will probe synchronously and the assumption that devices it provides
      will be immediately available after this.
      Signed-off-by: NLuis R. Rodriguez <mcgrof@suse.com>
      Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f2411da7
    • L
      module: add extra argument for parse_params() callback · ecc86170
      Luis R. Rodriguez 提交于
      This adds an extra argument onto parse_params() to be used
      as a way to make the unused callback a bit more useful and
      generic by allowing the caller to pass on a data structure
      of its choice. An example use case is to allow us to easily
      make module parameters for every module which we will do
      next.
      
      @ parse @
      identifier name, args, params, num, level_min, level_max;
      identifier unknown, param, val, doing;
      type s16;
      @@
       extern char *parse_args(const char *name,
       			 char *args,
       			 const struct kernel_param *params,
       			 unsigned num,
       			 s16 level_min,
       			 s16 level_max,
      +			 void *arg,
       			 int (*unknown)(char *param, char *val,
      					const char *doing
      +					, void *arg
      					));
      
      @ parse_mod @
      identifier name, args, params, num, level_min, level_max;
      identifier unknown, param, val, doing;
      type s16;
      @@
       char *parse_args(const char *name,
       			 char *args,
       			 const struct kernel_param *params,
       			 unsigned num,
       			 s16 level_min,
       			 s16 level_max,
      +			 void *arg,
       			 int (*unknown)(char *param, char *val,
      					const char *doing
      +					, void *arg
      					))
      {
      	...
      }
      
      @ parse_args_found @
      expression R, E1, E2, E3, E4, E5, E6;
      identifier func;
      @@
      
      (
      	R =
      	parse_args(E1, E2, E3, E4, E5, E6,
      +		   NULL,
      		   func);
      |
      	R =
      	parse_args(E1, E2, E3, E4, E5, E6,
      +		   NULL,
      		   &func);
      |
      	R =
      	parse_args(E1, E2, E3, E4, E5, E6,
      +		   NULL,
      		   NULL);
      |
      	parse_args(E1, E2, E3, E4, E5, E6,
      +		   NULL,
      		   func);
      |
      	parse_args(E1, E2, E3, E4, E5, E6,
      +		   NULL,
      		   &func);
      |
      	parse_args(E1, E2, E3, E4, E5, E6,
      +		   NULL,
      		   NULL);
      )
      
      @ parse_args_unused depends on parse_args_found @
      identifier parse_args_found.func;
      @@
      
      int func(char *param, char *val, const char *unused
      +		 , void *arg
      		 )
      {
      	...
      }
      
      @ mod_unused depends on parse_args_found @
      identifier parse_args_found.func;
      expression A1, A2, A3;
      @@
      
      -	func(A1, A2, A3);
      +	func(A1, A2, A3, NULL);
      
      Generated-by: Coccinelle SmPL
      Cc: cocci@systeme.lip6.fr
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Felipe Contreras <felipe.contreras@gmail.com>
      Cc: Ewan Milne <emilne@redhat.com>
      Cc: Jean Delvare <jdelvare@suse.de>
      Cc: Hannes Reinecke <hare@suse.de>
      Cc: Jani Nikula <jani.nikula@intel.com>
      Cc: linux-kernel@vger.kernel.org
      Reviewed-by: NTejun Heo <tj@kernel.org>
      Acked-by: NRusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: NLuis R. Rodriguez <mcgrof@suse.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ecc86170
  12. 14 5月, 2015 1 次提交
  13. 09 5月, 2015 1 次提交
  14. 09 4月, 2015 1 次提交
    • L
      Copy the kernel module data from user space in chunks · 3afe9f84
      Linus Torvalds 提交于
      Unlike most (all?) other copies from user space, kernel module loading
      is almost unlimited in size.  So we do a potentially huge
      "copy_from_user()" when we copy the module data from user space to the
      kernel buffer, which can be a latency concern when preemption is
      disabled (or voluntary).
      
      Also, because 'copy_from_user()' clears the tail of the kernel buffer on
      failures, even a *failed* copy can end up wasting a lot of time.
      
      Normally neither of these are concerns in real life, but they do trigger
      when doing stress-testing with trinity.  Running in a VM seems to add
      its own overheadm causing trinity module load testing to even trigger
      the watchdog.
      
      The simple fix is to just chunk up the module loading, so that it never
      tries to copy insanely big areas in one go.  That bounds the latency,
      and also the amount of (unnecessarily, in this case) cleared memory for
      the failure case.
      Reported-by: NSasha Levin <sasha.levin@oracle.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3afe9f84
  15. 08 4月, 2015 1 次提交
  16. 24 3月, 2015 2 次提交
  17. 23 3月, 2015 1 次提交
    • P
      lockdep: Fix the module unload key range freeing logic · 35a9393c
      Peter Zijlstra 提交于
      Module unload calls lockdep_free_key_range(), which removes entries
      from the data structures. Most of the lockdep code OTOH assumes the
      data structures are append only; in specific see the comments in
      add_lock_to_list() and look_up_lock_class().
      
      Clearly this has only worked by accident; make it work proper. The
      actual scenario to make it go boom would involve the memory freed by
      the module unlock being re-allocated and re-used for a lock inside of
      a rcu-sched grace period. This is a very unlikely scenario, still
      better plug the hole.
      
      Use RCU list iteration in all places and ammend the comments.
      
      Change lockdep_free_key_range() to issue a sync_sched() between
      removal from the lists and returning -- which results in the memory
      being freed. Further ensure the callers are placed correctly and
      comment the requirements.
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andrey Tsyvarev <tsyvarev@ispras.ru>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      35a9393c
  18. 13 3月, 2015 1 次提交
    • A
      kasan, module, vmalloc: rework shadow allocation for modules · a5af5aa8
      Andrey Ryabinin 提交于
      Current approach in handling shadow memory for modules is broken.
      
      Shadow memory could be freed only after memory shadow corresponds it is no
      longer used.  vfree() called from interrupt context could use memory its
      freeing to store 'struct llist_node' in it:
      
          void vfree(const void *addr)
          {
          ...
              if (unlikely(in_interrupt())) {
                  struct vfree_deferred *p = this_cpu_ptr(&vfree_deferred);
                  if (llist_add((struct llist_node *)addr, &p->list))
                          schedule_work(&p->wq);
      
      Later this list node used in free_work() which actually frees memory.
      Currently module_memfree() called in interrupt context will free shadow
      before freeing module's memory which could provoke kernel crash.
      
      So shadow memory should be freed after module's memory.  However, such
      deallocation order could race with kasan_module_alloc() in module_alloc().
      
      Free shadow right before releasing vm area.  At this point vfree()'d
      memory is not used anymore and yet not available for other allocations.
      New VM_KASAN flag used to indicate that vm area has dynamically allocated
      shadow memory so kasan frees shadow only if it was previously allocated.
      Signed-off-by: NAndrey Ryabinin <a.ryabinin@samsung.com>
      Acked-by: NRusty Russell <rusty@rustcorp.com.au>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a5af5aa8
  19. 06 3月, 2015 1 次提交
  20. 18 2月, 2015 1 次提交
  21. 14 2月, 2015 1 次提交
    • A
      kasan: enable instrumentation of global variables · bebf56a1
      Andrey Ryabinin 提交于
      This feature let us to detect accesses out of bounds of global variables.
      This will work as for globals in kernel image, so for globals in modules.
      Currently this won't work for symbols in user-specified sections (e.g.
      __init, __read_mostly, ...)
      
      The idea of this is simple.  Compiler increases each global variable by
      redzone size and add constructors invoking __asan_register_globals()
      function.  Information about global variable (address, size, size with
      redzone ...) passed to __asan_register_globals() so we could poison
      variable's redzone.
      
      This patch also forces module_alloc() to return 8*PAGE_SIZE aligned
      address making shadow memory handling (
      kasan_module_alloc()/kasan_module_free() ) more simple.  Such alignment
      guarantees that each shadow page backing modules address space correspond
      to only one module_alloc() allocation.
      Signed-off-by: NAndrey Ryabinin <a.ryabinin@samsung.com>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Cc: Konstantin Serebryany <kcc@google.com>
      Cc: Dmitry Chernenkov <dmitryc@google.com>
      Signed-off-by: NAndrey Konovalov <adech.fo@gmail.com>
      Cc: Yuri Gribov <tetra2005@gmail.com>
      Cc: Konstantin Khlebnikov <koct9i@gmail.com>
      Cc: Sasha Levin <sasha.levin@oracle.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: David Rientjes <rientjes@google.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      bebf56a1
  22. 11 2月, 2015 2 次提交
  23. 06 2月, 2015 2 次提交
  24. 22 1月, 2015 1 次提交
  25. 20 1月, 2015 1 次提交
    • R
      module: fix race in kallsyms resolution during module load success. · c7496379
      Rusty Russell 提交于
      The kallsyms routines (module_symbol_name, lookup_module_* etc) disable
      preemption to walk the modules rather than taking the module_mutex:
      this is because they are used for symbol resolution during oopses.
      
      This works because there are synchronize_sched() and synchronize_rcu()
      in the unload and failure paths.  However, there's one case which doesn't
      have that: the normal case where module loading succeeds, and we free
      the init section.
      
      We don't want a synchronize_rcu() there, because it would slow down
      module loading: this bug was introduced in 2009 to speed module
      loading in the first place.
      
      Thus, we want to do the free in an RCU callback.  We do this in the
      simplest possible way by allocating a new rcu_head: if we put it in
      the module structure we'd have to worry about that getting freed.
      Reported-by: NRui Xiang <rui.xiang@huawei.com>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      c7496379