linux-stable.git/drivers/md, branch v3.4.6

md/raid1: fix use-after-free bug in RAID1 data-check code.

2012-07-19T15:58:55+00:00

commit 2d4f4f3384d4ef4f7c571448e803a1ce721113d5 upstream.

This bug has been present ever since data-check was introduce
in 2.6.16.  However it would only fire if a data-check were
done on a degraded array, which was only possible if the array
has 3 or more devices.  This is certainly possible, but is quite
uncommon.

Since hot-replace was added in 3.3 it can happen more often as
the same condition can arise if not all possible replacements are
present.

The problem is that as soon as we submit the last read request, the
'r1_bio' structure could be freed at any time, so we really should
stop looking at it.  If the last device is being read from we will
stop looking at it.  However if the last device is not due to be read
from, we will still check the bio pointer in the r1_bio, but the
r1_bio might already be free.

So use the read_targets counter to make sure we stop looking for bios
to submit as soon as we have submitted them all.

This fix is suitable for any -stable kernel since 2.6.16.

Reported-by: Arnold Schulz 
Signed-off-by: NeilBrown 
Signed-off-by: Greg Kroah-Hartman

md/raid5: Do not add data_offset before call to is_badblock

2012-07-16T16:04:43+00:00

commit 6c0544e255dd6582a9899572e120fb55d9f672a4 upstream.

In chunk_aligned_read() we are adding data_offset before calling
is_badblock.  But is_badblock also adds data_offset, so that is bad.

So move the addition of data_offset to after the call to
is_badblock.

This bug was introduced by commit 31c176ecdf3563140e639
     md/raid5: avoid reading from known bad blocks.
which first appeared in 3.0.  So that patch is suitable for any
-stable kernel from 3.0.y onwards.  However it will need minor
revision for most of those (as the comment didn't appear until
recently).

Signed-off-by: majianpeng 
Signed-off-by: NeilBrown 
[bwh: Backported to 3.2: ignored missing comment]
Signed-off-by: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman

raid5: delayed stripe fix

2012-07-16T16:04:41+00:00

commit fab363b5ff502d1b39ddcfec04271f5858d9f26e upstream.

There isn't locking setting STRIPE_DELAYED and STRIPE_PREREAD_ACTIVE bits, but
the two bits have relationship. A delayed stripe can be moved to hold list only
when preread active stripe count is below IO_THRESHOLD. If a stripe has both
the bits set, such stripe will be in delayed list and preread count not 0,
which will make such stripe never leave delayed list.

Signed-off-by: Shaohua Li 
Signed-off-by: NeilBrown 
Signed-off-by: Greg Kroah-Hartman

dm persistent data: fix allocation failure in space map checker init

2012-07-16T16:04:26+00:00

commit b0239faaf87c38bb419c9264bf20817438ddc3a9 upstream.

If CONFIG_DM_DEBUG_SPACE_MAPS is enabled and memory is fragmented and a
sufficiently-large metadata device is used in a thin pool then the space
map checker will fail to allocate the memory it requires.

Switch from kmalloc to vmalloc to allow larger virtually contiguous
allocations for the space map checker's internal count arrays.

Reported-by: Vivek Goyal 
Signed-off-by: Mike Snitzer 
Signed-off-by: Alasdair G Kergon 
Signed-off-by: Greg Kroah-Hartman

dm persistent data: handle space map checker creation failure

2012-07-16T16:04:26+00:00

commit 62662303e7f590fdfbb0070ab820a0ad4267c119 upstream.

If CONFIG_DM_DEBUG_SPACE_MAPS is enabled and dm_sm_checker_create()
fails, dm_tm_create_internal() would still return success even though it
cleaned up all resources it was supposed to have created.  This will
lead to a kernel crash:

general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC
...
RIP: 0010:[]  [] dm_bufio_get_block_size+0x9/0x20
Call Trace:
  [] dm_bm_block_size+0xe/0x10
  [] sm_ll_init+0x78/0xd0
  [] sm_ll_new_disk+0x16/0xa0
  [] dm_sm_disk_create+0xfe/0x160
  [] dm_pool_metadata_open+0x16e/0x6a0
  [] pool_ctr+0x3f0/0x900
  [] dm_table_add_target+0x195/0x450
  [] table_load+0xe4/0x330
  [] ctl_ioctl+0x15a/0x2c0
  [] dm_ctl_ioctl+0x13/0x20
  [] do_vfs_ioctl+0x98/0x560
  [] sys_ioctl+0x91/0xa0
  [] system_call_fastpath+0x16/0x1b

Fix the space map checker code to return an appropriate ERR_PTR and have
dm_sm_disk_create() and dm_tm_create_internal() check for it with
IS_ERR.

Reported-by: Vivek Goyal 
Signed-off-by: Mike Snitzer 
Signed-off-by: Alasdair G Kergon 
Signed-off-by: Greg Kroah-Hartman

dm persistent data: fix shadow_info_leak on dm_tm_destroy

2012-07-16T16:04:26+00:00

commit 25d7cd6faa7ae6ed2565617c3ee2500ccb8a9f7f upstream.

Cleanup the shadow table before destroying the transaction manager.

Reference: leak was identified with kmemleak when running
test_discard_random_sectors in the thinp-test-suite.

Signed-off-by: Mike Snitzer 
Signed-off-by: Alasdair G Kergon 
Signed-off-by: Greg Kroah-Hartman

md/raid5: In ops_run_io, inc nr_pending before calling md_wait_for_blocked_rdev

2012-07-16T16:04:25+00:00

commit 1850753d2e6d9ca7856581ca5d3cf09521e6a5d7 upstream.

In ops_run_io(), the call to md_wait_for_blocked_rdev will decrement
nr_pending so we lose the reference we hold on the rdev.
So atomic_inc it first to maintain the reference.

This bug was introduced by commit  73e92e51b7969ef5477d
    md/raid5.  Don't write to known bad block on doubtful devices.

which appeared in 3.0, so patch is suitable for stable kernels since
then.

Signed-off-by: majianpeng 
Signed-off-by: NeilBrown 
Signed-off-by: Greg Kroah-Hartman

md/raid10: fix failure when trying to repair a read error.

2012-07-16T16:04:25+00:00

commit 055d3747dbf00ce85c6872ecca4d466638e80c22 upstream.

commit 58c54fcca3bac5bf9290cfed31c76e4c4bfbabaf
     md/raid10: handle further errors during fix_read_error better.

in 3.1 added "r10_sync_page_io" which takes an IO size in sectors.
But we were passing the IO size in bytes!!!
This resulting in bio_add_page failing, and empty request being sent
down, and a consequent BUG_ON in scsi_lib.

[fix missing space in error message at same time]

This fix is suitable for 3.1.y and later.

Reported-by: Christian Balzer 
Signed-off-by: NeilBrown 
Signed-off-by: Greg Kroah-Hartman

md/raid10: Don't try to recovery unmatched (and unused) chunks.

2012-07-16T16:04:25+00:00

commit fc448a18ae6219af9a73257b1fbcd009efab4a81 upstream.

If a RAID10 has an odd number of chunks - as might happen when there
are an odd number of devices - the last chunk has no pair and so is
not mirrored.  We don't store data there, but when recovering the last
device in an array we retry to recover that last chunk from a
non-existent location.  This results in an error, and the recovery
aborts.

When we get to that last chunk we should just stop - there is nothing
more to do anyway.

This bug has been present since the introduction of RAID10, so the
patch is appropriate for any -stable kernel.

Reported-by: Christian Balzer 
Tested-by: Christian Balzer 
Signed-off-by: NeilBrown 
Signed-off-by: Greg Kroah-Hartman

md: raid1/raid10: fix problem with merge_bvec_fn

2012-06-09T15:36:18+00:00

commit aba336bd1d46d6b0404b06f6915ed76150739057 upstream.

The new merge_bvec_fn which calls the corresponding function
in subsidiary devices requires that mddev->merge_check_needed
be set if any child has a merge_bvec_fn.

However were were only setting that when a device was hot-added,
not when a device was present from the start.

This bug was introduced in 3.4 so patch is suitable for 3.4.y
kernels.  However that are conflicts in raid10.c so a separate
patch will be needed for 3.4.y.

Reported-by: Sebastian Riemer 
Signed-off-by: NeilBrown 
Signed-off-by: Greg Kroah-Hartman