1. 23 Apr, 2009 2 commits
    • Theodore Ts'o's avatar
      ext4: Fix potential inode allocation soft lockup in Orlov allocator · b5451f7b
      Theodore Ts'o authored
      If the Orlov allocator is having trouble finding an appropriate block
      group, the fallback code could loop forever, causing a soft lockup
      warning in find_group_orlov():
      
      BUG: soft lockup - CPU#0 stuck for 61s! [cp:11728]
           ...
      Pid: 11728, comm: cp Not tainted (2.6.30-rc1-dirty #77) Lenovo          
      EIP: 0060:[<c021650e>] EFLAGS: 00000246 CPU: 0
      EIP is at ext4_get_group_desc+0x54/0x9d
          ...
      Call Trace:
       [<c0218021>] find_group_orlov+0x2ee/0x334
       [<c0120a5f>] ? sched_clock+0x8/0xb
       [<c02188e3>] ext4_new_inode+0x2cf/0xb1a
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      b5451f7b
    • Theodore Ts'o's avatar
      ext4: Make the extent validity check more paranoid · e84a26ce
      Theodore Ts'o authored
      Instead of just checking that the extent block number is greater or
      equal than s_first_data_block, make sure it it is not pointing into
      the block group descriptors, since that is clearly wrong.  This helps
      prevent filesystem from getting very badly corrupted in case an extent
      block is corrupted.
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      e84a26ce
  2. 14 Apr, 2009 3 commits
  3. 11 Apr, 2009 2 commits
    • Linus Torvalds's avatar
      Revert "ACPI battery: fix async boot oops" · b0cbc861
      Linus Torvalds authored
      This reverts commit 5d38258e, since the
      underlying problem got fixed properly in the previous commit ("async:
      Fix module loading async-work regression").
      
      Cc: Arkadiusz Miskiewicz <a.miskiewicz@gmail.com>
      Cc: Vegard Nossum <vegard.nossum@gmail.com>
      Cc: Len Brown <len.brown@intel.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      b0cbc861
    • Linus Torvalds's avatar
      async: Fix module loading async-work regression · d6de2c80
      Linus Torvalds authored
      Several drivers use asynchronous work to do device discovery, and we
      synchronize with them in the compiled-in case before we actually try to
      mount root filesystems etc.
      
      However, when compiled as modules, that synchronization is missing - the
      module loading completes, but the driver hasn't actually finished
      probing for devices, and that means that any user mode that expects to
      use the devices after the 'insmod' is now potentially broken.
      
      We already saw one case of a similar issue in the ACPI battery code,
      where the kernel itself expected the module to be all done, and unmapped
      the init memory - but the async device discovery was still running.
      That got hacked around by just removing the "__init" (see commit
      5d38258e "ACPI battery: fix async boot
      oops"), but the real fix is to just make the module loading wait for all
      async work to be completed.
      
      It will slow down module loading, but since common devices should be
      built in anyway, and since the bug is really annoying and hard to handle
      from user space (and caused several S3 resume regressions), the simple
      fix to wait is the right one.
      
      This fixes at least
      
      	http://bugzilla.kernel.org/show_bug.cgi?id=13063
      
      but probably a few other bugzilla entries too (12936, for example), and
      is confirmed to fix Rafael's storage driver breakage after resume bug
      report (no bugzilla entry).
      
      We should also be able to now revert that ACPI battery fix.
      Reported-and-tested-by: default avatarRafael J. Wysocki <rjw@suse.com>
      Tested-by: default avatarHeinz Diehl <htd@fancy-poultry.org>
      Acked-by: default avatarArjan van de Ven <arjan@linux.intel.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      d6de2c80
  4. 10 Apr, 2009 8 commits
  5. 09 Apr, 2009 25 commits