1. 14 1月, 2014 5 次提交
    • N
      md/raid10: fix bug when raid10 recovery fails to recover a block. · e8b84915
      NeilBrown 提交于
      commit e875ecea
          md/raid10 record bad blocks as needed during recovery.
      
      added code to the "cannot recover this block" path to record a bad
      block rather than fail the whole recovery.
      Unfortunately this new case was placed *after* r10bio was freed rather
      than *before*, yet it still uses r10bio.
      This is will crash with a null dereference.
      
      So move the freeing of r10bio down where it is safe.
      
      Cc: stable@vger.kernel.org (v3.1+)
      Fixes: e875eceaReported-by: NDamian Nowak <spam@nowaker.net>
      URL: https://bugzilla.kernel.org/show_bug.cgi?id=68181Signed-off-by: NNeilBrown <neilb@suse.de>
      e8b84915
    • N
      md/raid5: fix a recently broken BUG_ON(). · 5af9bef7
      NeilBrown 提交于
      commit 6d183de4
          md/raid5: fix newly-broken locking in get_active_stripe.
      
      simplified a BUG_ON, but removed too much so now it sometimes fires
      when it shouldn't.
      
      When the STRIPE_EXPANDING flag is set, the stripe_head might be on a
      special list while multiple stripe_heads are collected, or it might
      not be on any list, even a 'free' list when the refcount is zero.  As
      long as STRIPE_EXPANDING is set, it will be found and added back to a
      list eventually.
      
      So both of the BUG_ONs which test for the ->lru being empty or not
      need to avoid the case where STRIPE_EXPANDING is set.
      
      The patch which broke this was marked for -stable, so this patch needs
      to be applied to any branch that received 6d183de4
      
      Fixes: 6d183de4
      Cc: stable@vger.kernel.org (any release to which above was applied)
      Signed-off-by: NNeilBrown <neilb@suse.de>
      5af9bef7
    • N
      md/raid1: fix request counting bug in new 'barrier' code. · 41a336e0
      NeilBrown 提交于
      The new iobarrier implementation in raid1 (which keeps normal writes
      and resync activity separate) counts every request what is not before
      the current resync point in either next_window_requests or
      current_window_requests.
      It flags that the request is counted by setting ->start_next_window.
      
      allow_barrier follows this model exactly and decrements one of the
      *_window_requests if and only if ->start_next_window is set.
      
      However wait_barrier(), which increments *_window_requests uses a
      slightly different test for setting -.start_next_window (which is set
      from the return value of this function).
      So there is a possibility of the counts getting out of sync, and this
      leads to the resync hanging.
      
      So change wait_barrier() to return a non-zero value in exactly the
      same cases that it increments *_window_requests.
      
      But was introduced in 3.13-rc1.
      Reported-by: NBruno Wolff III <bruno@wolff.to>
      URL: https://bugzilla.kernel.org/show_bug.cgi?id=68061
      Fixes: 79ef3a8a
      Cc: majianpeng <majianpeng@gmail.com>
      Signed-off-by: NNeilBrown <neilb@suse.de>
      41a336e0
    • N
      md/raid10: fix two bugs in handling of known-bad-blocks. · b50c259e
      NeilBrown 提交于
      If we discover a bad block when reading we split the request and
      potentially read some of it from a different device.
      
      The code path of this has two bugs in RAID10.
      1/ we get a spin_lock with _irq, but unlock without _irq!!
      2/ The calculation of 'sectors_handled' is wrong, as can be clearly
         seen by comparison with raid1.c
      
      This leads to at least 2 warnings and a probable crash is a RAID10
      ever had known bad blocks.
      
      Cc: stable@vger.kernel.org (v3.1+)
      Fixes: 856e08e2Reported-by: NDamian Nowak <spam@nowaker.net>
      URL: https://bugzilla.kernel.org/show_bug.cgi?id=68181Signed-off-by: NNeilBrown <neilb@suse.de>
      b50c259e
    • N
      md/raid5: Fix possible confusion when multiple write errors occur. · 1cc03eb9
      NeilBrown 提交于
      commit 5d8c71f9
          md: raid5 crash during degradation
      
      Fixed a crash in an overly simplistic way which could leave
      R5_WriteError or R5_MadeGood set in the stripe cache for devices
      for which it is no longer relevant.
      When those devices are removed and spares added the flags are still
      set and can cause incorrect behaviour.
      
      commit 14a75d3e
          md/raid5: preferentially read from replacement device if possible.
      
      Fixed the same bug if a more effective way, so we can now revert
      the original commit.
      Reported-and-tested-by: NAlexander Lyakas <alex.bolshoy@gmail.com>
      Cc: stable@vger.kernel.org (3.2+ - 3.2 will need a different fix though)
      Fixes: 5d8c71f9Signed-off-by: NNeilBrown <neilb@suse.de>
      1cc03eb9
  2. 28 11月, 2013 3 次提交
  3. 22 11月, 2013 3 次提交
  4. 21 11月, 2013 22 次提交
  5. 20 11月, 2013 7 次提交
新手
引导
客服 返回
顶部