1. 16 12月, 2009 3 次提交
  2. 05 10月, 2009 1 次提交
  3. 21 9月, 2009 1 次提交
  4. 16 6月, 2009 1 次提交
  5. 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
  6. 22 4月, 2009 4 次提交
  7. 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
  8. 13 11月, 2008 1 次提交
  9. 02 11月, 2008 1 次提交
    • A
      saner FASYNC handling on file close · 233e70f4
      Al Viro 提交于
      As it is, all instances of ->release() for files that have ->fasync()
      need to remember to evict file from fasync lists; forgetting that
      creates a hole and we actually have a bunch that *does* forget.
      
      So let's keep our lives simple - let __fput() check FASYNC in
      file->f_flags and call ->fasync() there if it's been set.  And lose that
      crap in ->release() instances - leaving it there is still valid, but we
      don't have to bother anymore.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      233e70f4
  10. 31 10月, 2008 1 次提交
  11. 17 10月, 2008 1 次提交
  12. 23 9月, 2008 1 次提交
  13. 21 8月, 2008 1 次提交
  14. 30 7月, 2008 1 次提交
  15. 22 7月, 2008 1 次提交
  16. 12 7月, 2008 1 次提交
  17. 03 7月, 2008 1 次提交
  18. 21 6月, 2008 2 次提交
  19. 15 5月, 2008 1 次提交
  20. 29 4月, 2008 15 次提交