1. 07 8月, 2010 1 次提交
    • D
      Fix init ordering of /dev/console vs callers of modprobe · 31d1d48e
      David Howells 提交于
      Make /dev/console get initialised before any initialisation routine that
      invokes modprobe because if modprobe fails, it's going to want to open
      /dev/console, presumably to write an error message to.
      
      The problem with that is that if the /dev/console driver is not yet
      initialised, the chardev handler will call request_module() to invoke
      modprobe, which will fail, because we never compile /dev/console as a
      module.
      
      This will lead to a modprobe loop, showing the following in the kernel
      log:
      
      	request_module: runaway loop modprobe char-major-5-1
      	request_module: runaway loop modprobe char-major-5-1
      	request_module: runaway loop modprobe char-major-5-1
      	request_module: runaway loop modprobe char-major-5-1
      	request_module: runaway loop modprobe char-major-5-1
      
      This can happen, for example, when the built in md5 module can't find
      the built in cryptomgr module (because the latter fails to initialise).
      The md5 module comes before the call to tty_init(), presumably because
      'crypto' comes before 'drivers' alphabetically.
      
      Fix this by calling tty_init() from chrdev_init().
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      31d1d48e
  2. 24 9月, 2009 1 次提交
  3. 11 9月, 2009 1 次提交
  4. 10 8月, 2009 1 次提交
  5. 13 7月, 2009 1 次提交
  6. 12 6月, 2009 1 次提交
    • T
      fs: Remove i_cindex from struct inode · 9fd5746f
      Theodore Ts'o 提交于
      The only user of the i_cindex element in the inode structure is used
      is by the firewire drivers.  As part of an attempt to slim down the
      inode structure to save memory --- since a typical Linux system will
      have hundreds of thousands if not millions of inodes cached, a
      reduction in the size inode has high leverage.
      
      The firewire driver does not need i_cindex in any fast path, so it's
      simple enough to calculate when it is needed, instead of wasting space
      in the inode structure.
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      Cc: krh@redhat.com
      Cc: stefanr@s5r6.in-berlin.de
      Cc: linux-fsdevel@vger.kernel.org
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      9fd5746f
  7. 07 1月, 2009 1 次提交
  8. 23 10月, 2008 1 次提交
  9. 16 10月, 2008 1 次提交
  10. 21 6月, 2008 2 次提交
  11. 29 4月, 2008 1 次提交
  12. 09 2月, 2008 1 次提交
  13. 25 1月, 2008 2 次提交
  14. 17 10月, 2007 1 次提交
  15. 20 7月, 2007 1 次提交
  16. 05 4月, 2007 1 次提交
  17. 21 2月, 2007 1 次提交
  18. 13 2月, 2007 1 次提交
  19. 01 10月, 2006 1 次提交
  20. 30 9月, 2006 2 次提交
  21. 27 9月, 2006 1 次提交
  22. 15 7月, 2006 1 次提交
  23. 01 7月, 2006 1 次提交
  24. 27 6月, 2006 1 次提交
  25. 01 4月, 2006 1 次提交
  26. 29 3月, 2006 2 次提交
  27. 26 3月, 2006 1 次提交
  28. 21 3月, 2006 1 次提交
  29. 15 1月, 2006 1 次提交
  30. 13 7月, 2005 1 次提交
    • B
      [PATCH] cdev: cdev_put oops · 7da6844c
      Brian King 提交于
      While fixing an oops in the st driver in a dirty release path, I
      encountered an oops in cdev_put for cdevs allocated using cdev_alloc.  If
      cdev_del is called when the cdev kobject still has an open user, when the
      last cdev_put is called, the cdev_put will call kobject_put, which will end
      up ultimately releasing the cdev in cdev_dynamic_release.  Patch fixes the
      oops by preventing cdev_put from accessing freed memory.
      Signed-off-by: NBrian King <brking@us.ibm.com>
      Cc: <viro@parcelfarce.linux.theplanet.co.uk>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      7da6844c
  31. 29 6月, 2005 1 次提交
  32. 24 6月, 2005 1 次提交
  33. 06 5月, 2005 1 次提交
  34. 18 4月, 2005 1 次提交
  35. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4