1. 10 5月, 2007 4 次提交
  2. 09 12月, 2006 2 次提交
  3. 22 11月, 2006 1 次提交
  4. 09 11月, 2006 1 次提交
  5. 03 10月, 2006 1 次提交
  6. 28 8月, 2006 1 次提交
    • D
      [PATCH] dm: Fix deadlock under high i/o load in raid1 setup. · c06aad85
      Daniel Kobras 提交于
      On an nForce4-equipped machine with two SATA disk in raid1 setup using dmraid,
      we experienced frequent deadlock of the system under high i/o load.  'cat
      /dev/zero > ~/zero' was the most reliable way to reproduce them: Randomly
      after a few GB, 'cp' would be left in 'D' state along with kjournald and
      kmirrord.  The functions cp and kjournald were blocked in did vary, but
      kmirrord's wchan always pointed to 'mempool_alloc()'.  We've seen this pattern
      on 2.6.15 and 2.6.17 kernels.  http://lkml.org/lkml/2005/4/20/142 indicates
      that this problem has been around even before.
      
      So much for the facts, here's my interpretation: mempool_alloc() first tries
      to atomically allocate the requested memory, or falls back to hand out
      preallocated chunks from the mempool.  If both fail, it puts the calling
      process (kmirrord in this case) on a private waitqueue until somebody refills
      the pool.  Where the only 'somebody' is kmirrord itself, so we have a
      deadlock.
      
      I worked around this problem by falling back to a (blocking) kmalloc when
      before kmirrord would have ended up on the waitqueue.  This defeats part of
      the benefits of using the mempool, but at least keeps the system running.  And
      it could be done with a two-line change.  Note that mempool_alloc() clears the
      GFP_NOIO flag internally, and only uses it to decide whether to wait or return
      an error if immediate allocation fails, so the attached patch doesn't change
      behaviour in the non-deadlocking case.  Path is against current git
      (2.6.18-rc4), but should apply to earlier versions as well.  I've tested on
      2.6.15, where this patch makes the difference between random lockup and a
      stable system.
      Signed-off-by: NDaniel Kobras <kobras@linux.de>
      Acked-by: NAlasdair G Kergon <agk@redhat.com>
      Cc: <stable@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      c06aad85
  7. 27 6月, 2006 5 次提交
  8. 28 3月, 2006 2 次提交
    • A
      [PATCH] dm: remove SECTOR_FORMAT · 4ee218cd
      Andrew Morton 提交于
      We don't know what type sector_t has.  Sometimes it's unsigned long, sometimes
      it's unsigned long long.  For example on ppc64 it's unsigned long with
      CONFIG_LBD=n and on x86_64 it's unsigned long long with CONFIG_LBD=n.
      
      The way to handle all of this is to always use unsigned long long and to
      always typecast the sector_t when printing it.
      Acked-by: NAlasdair G Kergon <agk@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      4ee218cd
    • J
      [PATCH] drivers/md/dm-raid1.c: Fix inconsistent mirroring after interrupted recovery · 930d332a
      Jun'ichi Nomura 提交于
      dm-mirror has potential data corruption problem: while on-disk log shows
      that all disk contents are in-sync, actual contents of the disks are not
      synchronized.  This problem occurs if initial recovery (synching) is
      interrupted and resumed.
      
      Attached patch fixes this problem.
      
      Background:
      
      rh_dec() changes the region state from RH_NOSYNC (out-of-sync) to RH_CLEAN
      (in-sync), which results in the corresponding bit of clean_bits being set.
      
      This is harmful if on-disk log is used and the map is removed/suspended
      before the initial sync is completed.  The clean_bits is written down to
      the on-disk log at the map removal, and, upon resume, it's read and copied
      to sync_bits.  Since the recovery process refers to the sync_bits to find a
      region to be recovered, the region whose state was changed from RH_NOSYNC
      to RH_CLEAN is no longer recovered.
      
      If you haven't applied dm-raid1-read-balancing.patch proposed in dm-devel
      sometimes ago, the contents of the mirrored disk just corrupt silently.  If
      you have, balanced read may get bogus data from out-of-sync disks.
      
      The patch keeps RH_NOSYNC state unchanged.  It will be changed to
      RH_RECOVERING when recovery starts and get reclaimed when the recovery
      completes.  So it doesn't leak the region hash entry.
      
      Description:
      
      Keep RH_NOSYNC state unchanged when I/O on the region completes.
      
      rh_dec() changes the region state from RH_NOSYNC (out-of-sync) to RH_CLEAN
      (in-sync), which results in the corresponding bit of clean_bits being set.
      
      This is harmful if on-disk log is used and the map is removed/suspended
      before the initial sync is completed.  The clean_bits is written down to
      the on-disk log at the map removal, and, upon resume, it's read and copied
      to sync_bits.  Since the recovery process refers to the sync_bits to find a
      region to be recovered, the region whose state was changed from RH_NOSYNC
      to RH_CLEAN is no longer recovered.
      
      If you haven't applied dm-raid1-read-balancing.patch proposed in dm-devel
      sometimes ago, the contents of the mirrored disk just corrupt silently.  If
      you have, balanced read may get bogus data from out-of-sync disks.
      
      The RH_NOSYNC region will be changed to RH_RECOVERING when recovery starts
      on the region and get reclaimed when the recovery completes.  So it doesn't
      leak the region hash entry.
      
      Alasdair said:
      
        I've analysed the relevant part of the state machine and I believe that
        the patch is correct.
      
        (Further work on this code is still needed - this patch has the
        side-effect of holding onto memory unnecessarily for long periods of time
        under certain workloads - but better that than corrupting data.)
      Signed-off-by: NJun'ichi Nomura <j-nomura@ce.jp.nec.com>
      Acked-by: NAlasdair G Kergon <agk@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      930d332a
  9. 27 3月, 2006 1 次提交
  10. 07 1月, 2006 1 次提交
  11. 23 11月, 2005 1 次提交
  12. 09 10月, 2005 1 次提交
  13. 10 9月, 2005 1 次提交
    • J
      [PATCH] dm: fix rh_dec()/rh_inc() race in dm-raid1.c · 844e8d90
      Jun'ichi Nomura 提交于
      Fix another bug in dm-raid1.c that the dirty region may stay in or be moved
      to clean list and freed while in use.
      
      It happens as follows:
      
         CPU0                                   CPU1
         ------------------------------------------------------------------------------
         rh_dec()
           if (atomic_dec_and_test(pending))
              <the region is still marked dirty>
                                                rh_inc()
                                                  if the region is clean
                                                     mark the region dirty
                                                     and remove from clean list
              mark the region clean
              and move to clean list
                                                        atomic_inc(pending)
      
      At this stage, the region is in clean list and will be mistakenly reclaimed
      by rh_update_states() later.
      Signed-off-by: NJun'ichi Nomura <j-nomura@ce.jp.nec.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      844e8d90
  14. 05 8月, 2005 1 次提交
  15. 08 7月, 2005 1 次提交
  16. 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