1. 06 Feb, 2015 38 commits
  2. 30 Jan, 2015 2 commits
    • Greg Kroah-Hartman's avatar
      Linux 3.10.67 · 4227cffc
      Greg Kroah-Hartman authored
      4227cffc
    • NeilBrown's avatar
      md/raid5: fetch_block must fetch all the blocks handle_stripe_dirtying wants. · a4f2a8dd
      NeilBrown authored
      commit 108cef3a upstream.
      
      It is critical that fetch_block() and handle_stripe_dirtying()
      are consistent in their analysis of what needs to be loaded.
      Otherwise raid5 can wait forever for a block that won't be loaded.
      
      Currently when writing to a RAID5 that is resyncing, to a location
      beyond the resync offset, handle_stripe_dirtying chooses a
      reconstruct-write cycle, but fetch_block() assumes a
      read-modify-write, and a lockup can happen.
      
      So treat that case just like RAID6, just as we do in
      handle_stripe_dirtying.  RAID6 always does reconstruct-write.
      
      This bug was introduced when the behaviour of handle_stripe_dirtying
      was changed in 3.7, so the patch is suitable for any kernel since,
      though it will need careful merging for some versions.
      
      Cc: stable@vger.kernel.org (v3.7+)
      Fixes: a7854487Reported-by: default avatarHenry Cai <henryplusplus@gmail.com>
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a4f2a8dd