1. 20 5月, 2015 1 次提交
  2. 08 4月, 2015 1 次提交
  3. 17 3月, 2015 1 次提交
    • P
      livepatch: Fix subtle race with coming and going modules · 8cb2c2dc
      Petr Mladek 提交于
      There is a notifier that handles live patches for coming and going modules.
      It takes klp_mutex lock to avoid races with coming and going patches but
      it does not keep the lock all the time. Therefore the following races are
      possible:
      
        1. The notifier is called sometime in STATE_MODULE_COMING. The module
           is visible by find_module() in this state all the time. It means that
           new patch can be registered and enabled even before the notifier is
           called. It might create wrong order of stacked patches, see below
           for an example.
      
         2. New patch could still see the module in the GOING state even after
            the notifier has been called. It will try to initialize the related
            object structures but the module could disappear at any time. There
            will stay mess in the structures. It might even cause an invalid
            memory access.
      
      This patch solves the problem by adding a boolean variable into struct module.
      The value is true after the coming and before the going handler is called.
      New patches need to be applied when the value is true and they need to ignore
      the module when the value is false.
      
      Note that we need to know state of all modules on the system. The races are
      related to new patches. Therefore we do not know what modules will get
      patched.
      
      Also note that we could not simply ignore going modules. The code from the
      module could be called even in the GOING state until mod->exit() finishes.
      If we start supporting patches with semantic changes between function
      calls, we need to apply new patches to any still usable code.
      See below for an example.
      
      Finally note that the patch solves only the situation when a new patch is
      registered. There are no such problems when the patch is being removed.
      It does not matter who disable the patch first, whether the normal
      disable_patch() or the module notifier. There is nothing to do
      once the patch is disabled.
      
      Alternative solutions:
      ======================
      
      + reject new patches when a patched module is coming or going; this is ugly
      
      + wait with adding new patch until the module leaves the COMING and GOING
        states; this might be dangerous and complicated; we would need to release
        kgr_lock in the middle of the patch registration to avoid a deadlock
        with the coming and going handlers; also we might need a waitqueue for
        each module which seems to be even bigger overhead than the boolean
      
      + stop modules from entering COMING and GOING states; wait until modules
        leave these states when they are already there; looks complicated; we would
        need to ignore the module that asked to stop the others to avoid a deadlock;
        also it is unclear what to do when two modules asked to stop others and
        both are in COMING state (situation when two new patches are applied)
      
      + always register/enable new patches and fix up the potential mess (registered
        patches order) in klp_module_init(); this is nasty and prone to regressions
        in the future development
      
      + add another MODULE_STATE where the kallsyms are visible but the module is not
        used yet; this looks too complex; the module states are checked on "many"
        locations
      
      Example of patch stacking breakage:
      ===================================
      
      The notifier could _not_ _simply_ ignore already initialized module objects.
      For example, let's have three patches (P1, P2, P3) for functions a() and b()
      where a() is from vmcore and b() is from a module M. Something like:
      
      	a()	b()
      P1	a1()	b1()
      P2	a2()	b2()
      P3	a3()	b3(3)
      
      If you load the module M after all patches are registered and enabled.
      The ftrace ops for function a() and b() has listed the functions in this
      order:
      
      	ops_a->func_stack -> list(a3,a2,a1)
      	ops_b->func_stack -> list(b3,b2,b1)
      
      , so the pointer to b3() is the first and will be used.
      
      Then you might have the following scenario. Let's start with state when patches
      P1 and P2 are registered and enabled but the module M is not loaded. Then ftrace
      ops for b() does not exist. Then we get into the following race:
      
      CPU0					CPU1
      
      load_module(M)
      
        complete_formation()
      
        mod->state = MODULE_STATE_COMING;
        mutex_unlock(&module_mutex);
      
      					klp_register_patch(P3);
      					klp_enable_patch(P3);
      
      					# STATE 1
      
        klp_module_notify(M)
          klp_module_notify_coming(P1);
          klp_module_notify_coming(P2);
          klp_module_notify_coming(P3);
      
      					# STATE 2
      
      The ftrace ops for a() and b() then looks:
      
        STATE1:
      
      	ops_a->func_stack -> list(a3,a2,a1);
      	ops_b->func_stack -> list(b3);
      
        STATE2:
      	ops_a->func_stack -> list(a3,a2,a1);
      	ops_b->func_stack -> list(b2,b1,b3);
      
      therefore, b2() is used for the module but a3() is used for vmcore
      because they were the last added.
      
      Example of the race with going modules:
      =======================================
      
      CPU0					CPU1
      
      delete_module()  #SYSCALL
      
         try_stop_module()
           mod->state = MODULE_STATE_GOING;
      
         mutex_unlock(&module_mutex);
      
      					klp_register_patch()
      					klp_enable_patch()
      
      					#save place to switch universe
      
      					b()     # from module that is going
      					  a()   # from core (patched)
      
         mod->exit();
      
      Note that the function b() can be called until we call mod->exit().
      
      If we do not apply patch against b() because it is in MODULE_STATE_GOING,
      it will call patched a() with modified semantic and things might get wrong.
      
      [jpoimboe@redhat.com: use one boolean instead of two]
      Signed-off-by: NPetr Mladek <pmladek@suse.cz>
      Acked-by: NJosh Poimboeuf <jpoimboe@redhat.com>
      Acked-by: NRusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      8cb2c2dc
  4. 14 2月, 2015 1 次提交
    • A
      module: fix types of device tables aliases · 6301939d
      Andrey Ryabinin 提交于
      MODULE_DEVICE_TABLE() macro used to create aliases to device tables.
      Normally alias should have the same type as aliased symbol.
      
      Device tables are arrays, so they have 'struct type##_device_id[x]'
      types. Alias created by MODULE_DEVICE_TABLE() will have non-array type -
      	'struct type##_device_id'.
      
      This inconsistency confuses compiler, it could make a wrong assumption
      about variable's size which leads KASan to produce a false positive report
      about out of bounds access.
      
      For every global variable compiler calls __asan_register_globals() passing
      information about global variable (address, size, size with redzone, name
      ...) __asan_register_globals() poison symbols redzone to detect possible
      out of bounds accesses.
      
      When symbol has an alias __asan_register_globals() will be called as for
      symbol so for alias.  Compiler determines size of variable by size of
      variable's type.  Alias and symbol have the same address, so if alias have
      the wrong size part of memory that actually belongs to the symbol could be
      poisoned as redzone of alias symbol.
      
      By fixing type of alias symbol we will fix size of it, so
      __asan_register_globals() will not poison valid memory.
      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>
      6301939d
  5. 22 1月, 2015 1 次提交
  6. 11 11月, 2014 1 次提交
  7. 27 7月, 2014 2 次提交
  8. 13 3月, 2014 2 次提交
  9. 07 3月, 2014 1 次提交
  10. 16 1月, 2014 1 次提交
  11. 04 12月, 2013 1 次提交
  12. 23 9月, 2013 1 次提交
    • R
      module: remove rmmod --wait option. · 3f2b9c9c
      Rusty Russell 提交于
      The option to wait for a module reference count to reach zero was in
      the initial module implementation, but it was never supported in
      modprobe (you had to use rmmod --wait).  After discussion with Lucas,
      It has been deprecated (with a 10 second sleep) in kmod for the last
      year.
      
      This finally removes it: the flag will evoke a printk warning and a
      normal (non-blocking) remove attempt.
      
      Cc: Lucas De Marchi <lucas.de.marchi@gmail.com>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      3f2b9c9c
  13. 03 9月, 2013 1 次提交
    • L
      module: Fix mod->mkobj.kobj potentially freed too early · 942e4431
      Li Zhong 提交于
      DEBUG_KOBJECT_RELEASE helps to find the issue attached below.
      
      After some investigation, it seems the reason is:
      The mod->mkobj.kobj(ffffffffa01600d0 below) is freed together with mod
      itself in free_module(). However, its children still hold references to
      it, as the delay caused by DEBUG_KOBJECT_RELEASE. So when the
      child(holders below) tries to decrease the reference count to its parent
      in kobject_del(), BUG happens as it tries to access already freed memory.
      
      This patch tries to fix it by waiting for the mod->mkobj.kobj to be
      really released in the module removing process (and some error code
      paths).
      
      [ 1844.175287] kobject: 'holders' (ffff88007c1f1600): kobject_release, parent ffffffffa01600d0 (delayed)
      [ 1844.178991] kobject: 'notes' (ffff8800370b2a00): kobject_release, parent ffffffffa01600d0 (delayed)
      [ 1845.180118] kobject: 'holders' (ffff88007c1f1600): kobject_cleanup, parent ffffffffa01600d0
      [ 1845.182130] kobject: 'holders' (ffff88007c1f1600): auto cleanup kobject_del
      [ 1845.184120] BUG: unable to handle kernel paging request at ffffffffa01601d0
      [ 1845.185026] IP: [<ffffffff812cda81>] kobject_put+0x11/0x60
      [ 1845.185026] PGD 1a13067 PUD 1a14063 PMD 7bd30067 PTE 0
      [ 1845.185026] Oops: 0000 [#1] PREEMPT
      [ 1845.185026] Modules linked in: xfs libcrc32c [last unloaded: kprobe_example]
      [ 1845.185026] CPU: 0 PID: 18 Comm: kworker/0:1 Tainted: G           O 3.11.0-rc6-next-20130819+ #1
      [ 1845.185026] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
      [ 1845.185026] Workqueue: events kobject_delayed_cleanup
      [ 1845.185026] task: ffff88007ca51f00 ti: ffff88007ca5c000 task.ti: ffff88007ca5c000
      [ 1845.185026] RIP: 0010:[<ffffffff812cda81>]  [<ffffffff812cda81>] kobject_put+0x11/0x60
      [ 1845.185026] RSP: 0018:ffff88007ca5dd08  EFLAGS: 00010282
      [ 1845.185026] RAX: 0000000000002000 RBX: ffffffffa01600d0 RCX: ffffffff8177d638
      [ 1845.185026] RDX: ffff88007ca5dc18 RSI: 0000000000000000 RDI: ffffffffa01600d0
      [ 1845.185026] RBP: ffff88007ca5dd18 R08: ffffffff824e9810 R09: ffffffffffffffff
      [ 1845.185026] R10: ffff8800ffffffff R11: dead4ead00000001 R12: ffffffff81a95040
      [ 1845.185026] R13: ffff88007b27a960 R14: ffff88007c1f1600 R15: 0000000000000000
      [ 1845.185026] FS:  0000000000000000(0000) GS:ffffffff81a23000(0000) knlGS:0000000000000000
      [ 1845.185026] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      [ 1845.185026] CR2: ffffffffa01601d0 CR3: 0000000037207000 CR4: 00000000000006b0
      [ 1845.185026] Stack:
      [ 1845.185026]  ffff88007c1f1600 ffff88007c1f1600 ffff88007ca5dd38 ffffffff812cdb7e
      [ 1845.185026]  0000000000000000 ffff88007c1f1640 ffff88007ca5dd68 ffffffff812cdbfe
      [ 1845.185026]  ffff88007c974800 ffff88007c1f1640 ffff88007ff61a00 0000000000000000
      [ 1845.185026] Call Trace:
      [ 1845.185026]  [<ffffffff812cdb7e>] kobject_del+0x2e/0x40
      [ 1845.185026]  [<ffffffff812cdbfe>] kobject_delayed_cleanup+0x6e/0x1d0
      [ 1845.185026]  [<ffffffff81063a45>] process_one_work+0x1e5/0x670
      [ 1845.185026]  [<ffffffff810639e3>] ? process_one_work+0x183/0x670
      [ 1845.185026]  [<ffffffff810642b3>] worker_thread+0x113/0x370
      [ 1845.185026]  [<ffffffff810641a0>] ? rescuer_thread+0x290/0x290
      [ 1845.185026]  [<ffffffff8106bfba>] kthread+0xda/0xe0
      [ 1845.185026]  [<ffffffff814ff0f0>] ? _raw_spin_unlock_irq+0x30/0x60
      [ 1845.185026]  [<ffffffff8106bee0>] ? kthread_create_on_node+0x130/0x130
      [ 1845.185026]  [<ffffffff8150751a>] ret_from_fork+0x7a/0xb0
      [ 1845.185026]  [<ffffffff8106bee0>] ? kthread_create_on_node+0x130/0x130
      [ 1845.185026] Code: 81 48 c7 c7 28 95 ad 81 31 c0 e8 9b da 01 00 e9 4f ff ff ff 66 0f 1f 44 00 00 55 48 89 e5 53 48 89 fb 48 83 ec 08 48 85 ff 74 1d <f6> 87 00 01 00 00 01 74 1e 48 8d 7b 38 83 6b 38 01 0f 94 c0 84
      [ 1845.185026] RIP  [<ffffffff812cda81>] kobject_put+0x11/0x60
      [ 1845.185026]  RSP <ffff88007ca5dd08>
      [ 1845.185026] CR2: ffffffffa01601d0
      [ 1845.185026] ---[ end trace 49a70afd109f5653 ]---
      Signed-off-by: NLi Zhong <zhong@linux.vnet.ibm.com>
      Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      942e4431
  14. 20 8月, 2013 1 次提交
  15. 01 8月, 2013 1 次提交
  16. 15 3月, 2013 1 次提交
    • R
      CONFIG_SYMBOL_PREFIX: cleanup. · b92021b0
      Rusty Russell 提交于
      We have CONFIG_SYMBOL_PREFIX, which three archs define to the string
      "_".  But Al Viro broke this in "consolidate cond_syscall and
      SYSCALL_ALIAS declarations" (in linux-next), and he's not the first to
      do so.
      
      Using CONFIG_SYMBOL_PREFIX is awkward, since we usually just want to
      prefix it so something.  So various places define helpers which are
      defined to nothing if CONFIG_SYMBOL_PREFIX isn't set:
      
      1) include/asm-generic/unistd.h defines __SYMBOL_PREFIX.
      2) include/asm-generic/vmlinux.lds.h defines VMLINUX_SYMBOL(sym)
      3) include/linux/export.h defines MODULE_SYMBOL_PREFIX.
      4) include/linux/kernel.h defines SYMBOL_PREFIX (which differs from #7)
      5) kernel/modsign_certificate.S defines ASM_SYMBOL(sym)
      6) scripts/modpost.c defines MODULE_SYMBOL_PREFIX
      7) scripts/Makefile.lib defines SYMBOL_PREFIX on the commandline if
         CONFIG_SYMBOL_PREFIX is set, so that we have a non-string version
         for pasting.
      
      (arch/h8300/include/asm/linkage.h defines SYMBOL_NAME(), too).
      
      Let's solve this properly:
      1) No more generic prefix, just CONFIG_HAVE_UNDERSCORE_SYMBOL_PREFIX.
      2) Make linux/export.h usable from asm.
      3) Define VMLINUX_SYMBOL() and VMLINUX_SYMBOL_STR().
      4) Make everyone use them.
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      Reviewed-by: NJames Hogan <james.hogan@imgtec.com>
      Tested-by: James Hogan <james.hogan@imgtec.com> (metag)
      b92021b0
  17. 21 1月, 2013 1 次提交
  18. 12 1月, 2013 1 次提交
  19. 10 10月, 2012 1 次提交
    • R
      module: signature checking hook · 106a4ee2
      Rusty Russell 提交于
      We do a very simple search for a particular string appended to the module
      (which is cache-hot and about to be SHA'd anyway).  There's both a config
      option and a boot parameter which control whether we accept or fail with
      unsigned modules and modules that are signed with an unknown key.
      
      If module signing is enabled, the kernel will be tainted if a module is
      loaded that is unsigned or has a signature for which we don't have the
      key.
      
      (Useful feedback and tweaks by David Howells <dhowells@redhat.com>)
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      106a4ee2
  20. 26 3月, 2012 1 次提交
    • S
      module: move __module_get and try_module_get() out of line. · d53799be
      Steven Rostedt 提交于
      With the preempt, tracepoint and everything, it's getting a bit
      chubby.  For an Ubuntu-based config:
      
      Before:
      	$ size -t `find * -name '*.ko'` | grep TOTAL
      	56199906        3870760	1606616	61677282	3ad1ee2	(TOTALS)
      	$ size vmlinux
      	   text	   data	    bss	    dec	    hex	filename
      	8509342	 850368	3358720	12718430	 c2115e	vmlinux
      
      After:
      	$ size -t `find * -name '*.ko'` | grep TOTAL
      	56183760	3867892	1606616	61658268	3acd49c	(TOTALS)
      	$ size vmlinux
      	   text	   data	    bss	    dec	    hex	filename
      	8501842	 849088	3358720	12709650	 c1ef12	vmlinux
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      Acked-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> (made all out-of-line)
      d53799be
  21. 13 1月, 2012 1 次提交
  22. 31 10月, 2011 2 次提交
    • P
      module.h: relocate MODULE_PARM_DESC into moduleparam.h · 639938eb
      Paul Gortmaker 提交于
      There are files which use module_param and MODULE_PARM_DESC
      back to back.  They only include moduleparam.h which makes sense,
      but the implicit presence of module.h everywhere hid the fact
      that MODULE_PARM_DESC wasn't in moduleparam.h at all.  Relocate
      the macro to moduleparam.h so that the moduleparam infrastructure
      can be used independently of module.h
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      639938eb
    • P
      module.h: split out the EXPORT_SYMBOL into export.h · f5016932
      Paul Gortmaker 提交于
      A lot of files pull in module.h when all they are really
      looking for is the basic EXPORT_SYMBOL functionality. The
      recent data from Ingo[1] shows that this is one of several
      instances that has a significant impact on compile times,
      and it should be targeted for factoring out (as done here).
      
      Note that several commonly used header files in include/*
      directly include <linux/module.h> themselves (some 34 of them!)
      The most commonly used ones of these will have to be made
      independent of module.h before the full benefit of this change
      can be realized.
      
      We also transition THIS_MODULE from module.h to export.h,
      since there are lots of files with subsystem structs that
      in turn will have a struct module *owner and only be doing:
      
      	.owner = THIS_MODULE;
      
      and absolutely nothing else modular. So, we also want to have
      the THIS_MODULE definition present in the lightweight header.
      
      [1] https://lkml.org/lkml/2011/5/23/76Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      f5016932
  23. 11 8月, 2011 1 次提交
    • M
      Tracepoint: Dissociate from module mutex · b75ef8b4
      Mathieu Desnoyers 提交于
      Copy the information needed from struct module into a local module list
      held within tracepoint.c from within the module coming/going notifier.
      
      This vastly simplifies locking of tracepoint registration /
      unregistration, because we don't have to take the module mutex to
      register and unregister tracepoints anymore. Steven Rostedt ran into
      dependency problems related to modules mutex vs kprobes mutex vs ftrace
      mutex vs tracepoint mutex that seems to be hard to fix without removing
      this dependency between tracepoint and module mutex. (note: it should be
      investigated whether kprobes could benefit of being dissociated from the
      modules mutex too.)
      
      This also fixes module handling of tracepoint list iterators, because it
      was expecting the list to be sorted by pointer address. Given we have
      control on our own list now, it's OK to sort this list which has
      tracepoints as its only purpose. The reason why this sorting is required
      is to handle the fact that seq files (and any read() operation from
      user-space) cannot hold the tracepoint mutex across multiple calls, so
      list entries may vanish between calls. With sorting, the tracepoint
      iterator becomes usable even if the list don't contain the exact item
      pointed to by the iterator anymore.
      Signed-off-by: NMathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Acked-by: NJason Baron <jbaron@redhat.com>
      CC: Ingo Molnar <mingo@elte.hu>
      CC: Lai Jiangshan <laijs@cn.fujitsu.com>
      CC: Peter Zijlstra <a.p.zijlstra@chello.nl>
      CC: Thomas Gleixner <tglx@linutronix.de>
      CC: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Link: http://lkml.kernel.org/r/20110810191839.GC8525@KrystalSigned-off-by: NSteven Rostedt <rostedt@goodmis.org>
      b75ef8b4
  24. 24 7月, 2011 2 次提交
    • K
      module: add /sys/module/<name>/uevent files · 88bfa324
      Kay Sievers 提交于
      Userspace wants to manage module parameters with udev rules.
      This currently only works for loaded modules, but not for
      built-in ones.
      
      To allow access to the built-in modules we need to
      re-trigger all module load events that happened before any
      userspace was running. We already do the same thing for all
      devices, subsystems(buses) and drivers.
      
      This adds the currently missing /sys/module/<name>/uevent files
      to all module entries.
      Signed-off-by: NKay Sievers <kay.sievers@vrfy.org>
      Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> (split & trivial fix)
      88bfa324
    • K
      module: change attr callbacks to take struct module_kobject · 4befb026
      Kay Sievers 提交于
      This simplifies the next patch, where we have an attribute on a
      builtin module (ie. module == NULL).
      Signed-off-by: NKay Sievers <kay.sievers@vrfy.org>
      Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> (split into 2)
      4befb026
  25. 19 5月, 2011 5 次提交
  26. 22 2月, 2011 1 次提交
  27. 03 2月, 2011 2 次提交
    • M
      tracepoints: Fix section alignment using pointer array · 65498646
      Mathieu Desnoyers 提交于
      Make the tracepoints more robust, making them solid enough to handle compiler
      changes by not relying on anything based on compiler-specific behavior with
      respect to structure alignment. Implement an approach proposed by David Miller:
      use an array of const pointers to refer to the individual structures, and export
      this pointer array through the linker script rather than the structures per se.
      It will consume 32 extra bytes per tracepoint (24 for structure padding and 8
      for the pointers), but are less likely to break due to compiler changes.
      
      History:
      
      commit 7e066fb8 tracepoints: add DECLARE_TRACE() and DEFINE_TRACE()
      added the aligned(32) type and variable attribute to the tracepoint structures
      to deal with gcc happily aligning statically defined structures on 32-byte
      multiples.
      
      One attempt was to use a 8-byte alignment for tracepoint structures by applying
      both the variable and type attribute to tracepoint structures definitions and
      declarations. It worked fine with gcc 4.5.1, but broke with gcc 4.4.4 and 4.4.5.
      
      The reason is that the "aligned" attribute only specify the _minimum_ alignment
      for a structure, leaving both the compiler and the linker free to align on
      larger multiples. Because tracepoint.c expects the structures to be placed as an
      array within each section, up-alignment cause NULL-pointer exceptions due to the
      extra unexpected padding.
      
      (this patch applies on top of -tip)
      Signed-off-by: NMathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      LKML-Reference: <20110126222622.GA10794@Krystal>
      CC: Frederic Weisbecker <fweisbec@gmail.com>
      CC: Ingo Molnar <mingo@elte.hu>
      CC: Thomas Gleixner <tglx@linutronix.de>
      CC: Andrew Morton <akpm@linux-foundation.org>
      CC: Peter Zijlstra <peterz@infradead.org>
      CC: Rusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      65498646
    • S
      tracing: Replace trace_event struct array with pointer array · e4a9ea5e
      Steven Rostedt 提交于
      Currently the trace_event structures are placed in the _ftrace_events
      section, and at link time, the linker makes one large array of all
      the trace_event structures. On boot up, this array is read (much like
      the initcall sections) and the events are processed.
      
      The problem is that there is no guarantee that gcc will place complex
      structures nicely together in an array format. Two structures in the
      same file may be placed awkwardly, because gcc has no clue that they
      are suppose to be in an array.
      
      A hack was used previous to force the alignment to 4, to pack the
      structures together. But this caused alignment issues with other
      architectures (sparc).
      
      Instead of packing the structures into an array, the structures' addresses
      are now put into the _ftrace_event section. As pointers are always the
      natural alignment, gcc should always pack them tightly together
      (otherwise initcall, extable, etc would also fail).
      
      By having the pointers to the structures in the section, we can still
      iterate the trace_events without causing unnecessary alignment problems
      with other architectures, or depending on the current behaviour of
      gcc that will likely change in the future just to tick us kernel developers
      off a little more.
      
      The _ftrace_event section is also moved into the .init.data section
      as it is now only needed at boot up.
      Suggested-by: NDavid Miller <davem@davemloft.net>
      Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      e4a9ea5e
  28. 24 1月, 2011 2 次提交
  29. 24 11月, 2010 1 次提交
  30. 18 11月, 2010 1 次提交
    • M
      x86: Add RO/NX protection for loadable kernel modules · 84e1c6bb
      matthieu castet 提交于
      This patch is a logical extension of the protection provided by
      CONFIG_DEBUG_RODATA to LKMs. The protection is provided by
      splitting module_core and module_init into three logical parts
      each and setting appropriate page access permissions for each
      individual section:
      
       1. Code: RO+X
       2. RO data: RO+NX
       3. RW data: RW+NX
      
      In order to achieve proper protection, layout_sections() have
      been modified to align each of the three parts mentioned above
      onto page boundary. Next, the corresponding page access
      permissions are set right before successful exit from
      load_module(). Further, free_module() and sys_init_module have
      been modified to set module_core and module_init as RW+NX right
      before calling module_free().
      
      By default, the original section layout and access flags are
      preserved. When compiled with CONFIG_DEBUG_SET_MODULE_RONX=y,
      the patch will page-align each group of sections to ensure that
      each page contains only one type of content and will enforce
      RO/NX for each group of pages.
      
        -v1: Initial proof-of-concept patch.
        -v2: The patch have been re-written to reduce the number of #ifdefs
             and to make it architecture-agnostic. Code formatting has also
             been corrected.
        -v3: Opportunistic RO/NX protection is now unconditional. Section
             page-alignment is enabled when CONFIG_DEBUG_RODATA=y.
        -v4: Removed most macros and improved coding style.
        -v5: Changed page-alignment and RO/NX section size calculation
        -v6: Fixed comments. Restricted RO/NX enforcement to x86 only
        -v7: Introduced CONFIG_DEBUG_SET_MODULE_RONX, added
             calls to set_all_modules_text_rw() and set_all_modules_text_ro()
             in ftrace
        -v8: updated for compatibility with linux 2.6.33-rc5
        -v9: coding style fixes
       -v10: more coding style fixes
       -v11: minor adjustments for -tip
       -v12: minor adjustments for v2.6.35-rc2-tip
       -v13: minor adjustments for v2.6.37-rc1-tip
      Signed-off-by: NSiarhei Liakh <sliakh.lkml@gmail.com>
      Signed-off-by: NXuxian Jiang <jiang@cs.ncsu.edu>
      Acked-by: NArjan van de Ven <arjan@linux.intel.com>
      Reviewed-by: NJames Morris <jmorris@namei.org>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      Cc: Andi Kleen <ak@muc.de>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      Cc: Dave Jones <davej@redhat.com>
      Cc: Kees Cook <kees.cook@canonical.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      LKML-Reference: <4CE2F914.9070106@free.fr>
      [ minor cleanliness edits, -v14: build failure fix ]
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      84e1c6bb