1. 28 5月, 2010 2 次提交
  2. 19 3月, 2010 1 次提交
  3. 05 10月, 2009 1 次提交
  4. 22 5月, 2009 1 次提交
    • C
      ipmi: fix ipmi_si modprobe hang · 9a2845c4
      Corey Minyard 提交于
      Instead of queuing IPMB messages before channel initialization, just
      throw them away.  Nobody will be listening for them at this point,
      anyway, and they will clog up the queue and nothing will be delivered
      if we queue them.
      
      Also set the current channel to the number of channels, as this value
      is used to tell if the channel information has been initialized.
      Signed-off-by: NCorey Minyard <cminyard@mvista.com>
      Cc: Ferenc Wagner <wferi@niif.hu>
      Cc: Dan Frazier <dannf@hp.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9a2845c4
  5. 22 4月, 2009 2 次提交
  6. 31 3月, 2009 1 次提交
    • A
      proc 2/2: remove struct proc_dir_entry::owner · 99b76233
      Alexey Dobriyan 提交于
      Setting ->owner as done currently (pde->owner = THIS_MODULE) is racy
      as correctly noted at bug #12454. Someone can lookup entry with NULL
      ->owner, thus not pinning enything, and release it later resulting
      in module refcount underflow.
      
      We can keep ->owner and supply it at registration time like ->proc_fops
      and ->data.
      
      But this leaves ->owner as easy-manipulative field (just one C assignment)
      and somebody will forget to unpin previous/pin current module when
      switching ->owner. ->proc_fops is declared as "const" which should give
      some thoughts.
      
      ->read_proc/->write_proc were just fixed to not require ->owner for
      protection.
      
      rmmod'ed directories will be empty and return "." and ".." -- no harm.
      And directories with tricky enough readdir and lookup shouldn't be modular.
      We definitely don't want such modular code.
      
      Removing ->owner will also make PDE smaller.
      
      So, let's nuke it.
      
      Kudos to Jeff Layton for reminding about this, let's say, oversight.
      
      http://bugzilla.kernel.org/show_bug.cgi?id=12454Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
      99b76233
  7. 13 11月, 2008 1 次提交
  8. 29 4月, 2008 9 次提交
  9. 07 2月, 2008 2 次提交
  10. 19 10月, 2007 2 次提交
  11. 17 10月, 2007 1 次提交
  12. 20 7月, 2007 1 次提交
  13. 12 7月, 2007 1 次提交
    • T
      sysfs: kill unnecessary attribute->owner · 7b595756
      Tejun Heo 提交于
      sysfs is now completely out of driver/module lifetime game.  After
      deletion, a sysfs node doesn't access anything outside sysfs proper,
      so there's no reason to hold onto the attribute owners.  Note that
      often the wrong modules were accounted for as owners leading to
      accessing removed modules.
      
      This patch kills now unnecessary attribute->owner.  Note that with
      this change, userland holding a sysfs node does not prevent the
      backing module from being unloaded.
      
      For more info regarding lifetime rule cleanup, please read the
      following message.
      
        http://article.gmane.org/gmane.linux.kernel/510293
      
      (tweaked by Greg to not delete the field just yet, to make it easier to
      merge things properly.)
      Signed-off-by: NTejun Heo <htejun@gmail.com>
      Cc: Cornelia Huck <cornelia.huck@de.ibm.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      7b595756
  14. 15 2月, 2007 1 次提交
    • T
      [PATCH] remove many unneeded #includes of sched.h · cd354f1a
      Tim Schmielau 提交于
      After Al Viro (finally) succeeded in removing the sched.h #include in module.h
      recently, it makes sense again to remove other superfluous sched.h includes.
      There are quite a lot of files which include it but don't actually need
      anything defined in there.  Presumably these includes were once needed for
      macros that used to live in sched.h, but moved to other header files in the
      course of cleaning it up.
      
      To ease the pain, this time I did not fiddle with any header files and only
      removed #includes from .c-files, which tend to cause less trouble.
      
      Compile tested against 2.6.20-rc2 and 2.6.20-rc2-mm2 (with offsets) on alpha,
      arm, i386, ia64, mips, powerpc, and x86_64 with allnoconfig, defconfig,
      allmodconfig, and allyesconfig as well as a few randconfigs on x86_64 and all
      configs in arch/arm/configs on arm.  I also checked that no new warnings were
      introduced by the patch (actually, some warnings are removed that were emitted
      by unnecessarily included header files).
      Signed-off-by: NTim Schmielau <tim@physik3.uni-rostock.de>
      Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      cd354f1a
  15. 12 2月, 2007 2 次提交
    • A
      [PATCH] proc: remove useless (and buggy) ->nlink settings · b653d081
      Alexey Dobriyan 提交于
      Bug: pnx8550 code creates directory but resets ->nlink to 1.
      
      create_proc_entry() et al will correctly set ->nlink for you.
      Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: Corey Minyard <minyard@acm.org>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Cc: Kyle McMartin <kyle@mcmartin.ca>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Greg KH <greg@kroah.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b653d081
    • C
      [PATCH] IPMI: Fix some RCU problems · 78ba2faf
      Corey Minyard 提交于
      Fix some RCU problem pointed out by Paul McKenney of IBM.  These are:
      
      The wholesale move of the command receivers list into a new list was not
      safe because the list will point to the new tail during a traversal, so the
      traversal will never end on a reader if this happens during a read.
      
      Memory barriers were needed to handle proper ordering of the setting of the
      IPMI interface as valid.  Readers might not see proper ordering of data
      otherwise.
      
      In ipmi_smi_watcher_register(), the use of the _rcu suffix on the list is
      unnecessary.
      
      This require the list_splice_init_rcu() patch previously posted.
      Signed-off-by: NCorey Minyard <minyard@acm.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      78ba2faf
  16. 31 1月, 2007 1 次提交
  17. 11 12月, 2006 2 次提交
  18. 08 12月, 2006 6 次提交
  19. 17 11月, 2006 1 次提交
    • Z
      [PATCH] ipmi: use platform_device_add() instead of platform_device_register()... · b48f5457
      Zhang, Yanmin 提交于
      [PATCH] ipmi: use platform_device_add() instead of platform_device_register() to register device allocated dynamically
      
      I got below warning when running 2.6.19-rc5-mm1 on my ia64 machine.
      
      WARNING at lib/kobject.c:172 kobject_init()
      
      Call Trace:
       [<a0000001000137c0>] show_stack+0x40/0xa0
                                      sp=e0000002ff9f7bc0 bsp=e0000002ff9f0d10
       [<a000000100013850>] dump_stack+0x30/0x60
                                      sp=e0000002ff9f7d90 bsp=e0000002ff9f0cf8
       [<a000000100407bb0>] kobject_init+0x90/0x160
                                      sp=e0000002ff9f7d90 bsp=e0000002ff9f0cd0
       [<a0000001005ae080>] device_initialize+0x40/0x1c0
                                      sp=e0000002ff9f7da0 bsp=e0000002ff9f0cb0
       [<a0000001005b88c0>] platform_device_register+0x20/0x60
                                      sp=e0000002ff9f7dd0 bsp=e0000002ff9f0c90
       [<a000000100592560>] try_smi_init+0xbc0/0x11e0
                                      sp=e0000002ff9f7dd0 bsp=e0000002ff9f0c50
       [<a000000100594900>] init_ipmi_si+0xaa0/0x12e0
                                      sp=e0000002ff9f7de0 bsp=e0000002ff9f0bd8
       [<a000000100009910>] init+0x350/0x780
                                      sp=e0000002ff9f7e00 bsp=e0000002ff9f0ba8
       [<a000000100011d30>] kernel_thread_helper+0x30/0x60
                                      sp=e0000002ff9f7e30 bsp=e0000002ff9f0b80
       [<a0000001000090c0>] start_kernel_thread+0x20/0x40
                                      sp=e0000002ff9f7e30 bsp=e0000002ff9f0b80
      WARNING at lib/kobject.c:172 kobject_init()
      
      Call Trace:
       [<a0000001000137c0>] show_stack+0x40/0xa0
                                      sp=e0000002ff9f7b40 bsp=e0000002ff9f0db0
       [<a000000100013850>] dump_stack+0x30/0x60
                                      sp=e0000002ff9f7d10 bsp=e0000002ff9f0d98
       [<a000000100407bb0>] kobject_init+0x90/0x160
                                      sp=e0000002ff9f7d10 bsp=e0000002ff9f0d70
       [<a0000001005ae080>] device_initialize+0x40/0x1c0
                                      sp=e0000002ff9f7d20 bsp=e0000002ff9f0d50
       [<a0000001005b88c0>] platform_device_register+0x20/0x60
                                      sp=e0000002ff9f7d50 bsp=e0000002ff9f0d30
       [<a00000010058ac00>] ipmi_register_smi+0xcc0/0x18e0
                                      sp=e0000002ff9f7d50 bsp=e0000002ff9f0c90
       [<a000000100592600>] try_smi_init+0xc60/0x11e0
                                      sp=e0000002ff9f7dd0 bsp=e0000002ff9f0c50
       [<a000000100594900>] init_ipmi_si+0xaa0/0x12e0
                                      sp=e0000002ff9f7de0 bsp=e0000002ff9f0bd8
       [<a000000100009910>] init+0x350/0x780
                                      sp=e0000002ff9f7e00 bsp=e0000002ff9f0ba8
       [<a000000100011d30>] kernel_thread_helper+0x30/0x60
                                      sp=e0000002ff9f7e30 bsp=e0000002ff9f0b80
       [<a0000001000090c0>] start_kernel_thread+0x20/0x40
                                      sp=e0000002ff9f7e30 bsp=e0000002ff9f0b80
      
      The root cause is the device struct is initialized twice.
      
      If the device is allocated dynamically by platform_device_alloc,
      platform_device_alloc will initialize struct device, then,
      platform_device_add should be used to register the device.
      
      The difference between platform_device_register and platform_device_add is
      platform_device_register will initiate the device while platform_device_add
      won't.
      Signed-off-by: NZhang Yanmin <yanmin.zhang@intel.com>
      Cc: Corey Minyard <minyard@acm.org>
      Cc: Greg KH <greg@kroah.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      b48f5457
  20. 13 11月, 2006 1 次提交
  21. 09 11月, 2006 1 次提交