1. 15 3月, 2011 1 次提交
    • T
      Fix corrupted OSF partition table parsing · 1eafbfeb
      Timo Warns 提交于
      The kernel automatically evaluates partition tables of storage devices.
      The code for evaluating OSF partitions contains a bug that leaks data
      from kernel heap memory to userspace for certain corrupted OSF
      partitions.
      
      In more detail:
      
        for (i = 0 ; i < le16_to_cpu(label->d_npartitions); i++, partition++) {
      
      iterates from 0 to d_npartitions - 1, where d_npartitions is read from
      the partition table without validation and partition is a pointer to an
      array of at most 8 d_partitions.
      
      Add the proper and obvious validation.
      Signed-off-by: NTimo Warns <warns@pre-sense.de>
      Cc: stable@kernel.org
      [ Changed the patch trivially to not repeat the whole le16_to_cpu()
        thing, and to use an explicit constant for the magic value '8' ]
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      1eafbfeb
  2. 14 3月, 2011 12 次提交
  3. 13 3月, 2011 3 次提交
  4. 12 3月, 2011 1 次提交
    • C
      Btrfs: break out of shrink_delalloc earlier · 36e39c40
      Chris Mason 提交于
      Josef had changed shrink_delalloc to exit after three shrink
      attempts, which wasn't quite enough because new writers could
      race in and steal free space.
      
      But it also fixed deadlocks and stalls as we tried to recover
      delalloc reservations.  The code was tweaked to loop 1024
      times, and would reset the counter any time a small amount
      of progress was made.  This was too drastic, and with a
      lot of writers we can end up stuck in shrink_delalloc forever.
      
      The shrink_delalloc loop is fairly complex because the caller is looping
      too, and the caller will go ahead and force a transaction commit to make
      sure we reclaim space.
      
      This reworks things to exit shrink_delalloc when we've forced some
      writeback and the delalloc reservations have gone down.  This means
      the writeback has not just started but has also finished at
      least some of the metadata changes required to reclaim delalloc
      space.
      
      If we've got this wrong, we're returning ENOSPC too early, which
      is a big improvement over the current behavior of hanging the machine.
      
      Test 224 in xfstests hammers on this nicely, and with 1000 writers
      trying to fill a 1GB drive we get our first ENOSPC at 93% full.  The
      other writers are able to continue until we get 100%.
      
      This is a worst case test for btrfs because the 1000 writers are doing
      small IO, and the small FS size means we don't have a lot of room
      for metadata chunks.
      Signed-off-by: NChris Mason <chris.mason@oracle.com>
      36e39c40
  5. 11 3月, 2011 22 次提交
  6. 10 3月, 2011 1 次提交