linux.git/drivers/md, branch v3.5-rc6

Merge tag 'md-3.5-fixes' of git://neil.brown.name/md

2012-07-04T01:05:35+00:00

Pull raid10 build failure fix from NeilBrown:
 "I really shouldn't do important things late in the day.  It seems that
  I get careless."

* tag 'md-3.5-fixes' of git://neil.brown.name/md:
  md/raid10: fix careless build error

md/raid10: fix careless build error

2012-07-03T23:35:35+00:00

build error introduced by commit b357f04a67c2aeee8

That function doesn't get extra args until a later patch.  Bother.

Reported-by: Fengguang Wu  
Reported-by: Simon Kirby 
Reported-by: Tobias Klausmann 
Signed-off-by: NeilBrown

Merge tag 'dm-3.5-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/agk/linux-dm

2012-07-03T18:08:16+00:00

Pull device-mapper fixes from Alasdair G Kergon:
 "Four minor thin provisioning fixes and correct and update dm-verity
  documentation."

* tag 'dm-3.5-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/agk/linux-dm:
  dm: verity fix documentation
  dm persistent data: fix allocation failure in space map checker init
  dm persistent data: handle space map checker creation failure
  dm persistent data: fix shadow_info_leak on dm_tm_destroy
  dm thin: commit metadata before creating metadata snapshot

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

2012-07-03T11:55:37+00:00

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 
Cc: stable@kernel.org
Signed-off-by: Mike Snitzer 
Signed-off-by: Alasdair G Kergon

dm persistent data: handle space map checker creation failure

2012-07-03T11:55:35+00:00

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 
Cc: stable@vger.kernel.org
Signed-off-by: Alasdair G Kergon

dm persistent data: fix shadow_info_leak on dm_tm_destroy

2012-07-03T11:55:33+00:00

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 
Cc: stable@vger.kernel.org
Signed-off-by: Alasdair G Kergon

dm thin: commit metadata before creating metadata snapshot

2012-07-03T11:55:31+00:00

Userland sometimes sees a corrupt metadata block if metadata is changing
rapidly when a metadata snapshot is reserved for userland,  To make the
problem go away, commit before we take the metadata snapshot (which is a
sensible thing to do anyway).

The checksums mean userland spots this corruption immediately so there's
no risk of acting on incorrect data.  No corruption exists from the
kernel's point of view, and thin_check passes after pool shutdown.

I believe this is to do with shared blocks at the first level of the
{device, mapping} btree.  Prior to the metadata-snap support no sharing
at this level was possible, so this patch is only required after commit
cc8394d86f045b86ff303d3c9e4ce47d97148951 ("dm thin: provide userspace
access to pool metadata").

Signed-off-by: Joe Thornber 
Signed-off-by: Mike Snitzer 
Signed-off-by: Alasdair G Kergon

md: fix up plugging (again).

2012-07-03T07:45:31+00:00

The value returned by "mddev_check_plug" is only valid until the
next 'schedule' as that will unplug things.  This could happen at any
call to mempool_alloc.
So just calling mddev_check_plug at the start doesn't really make
sense.

So call it just before, or just after, queuing things for the thread.
As the action that happens at unplug is to wake the thread, this makes
lots of sense.
If we cannot add a plug (which requires a small GFP_ATOMIC alloc) we
wake thread immediately.

RAID5 is a bit different.  Requests are queued for the thread and the
thread is woken by release_stripe.  So we don't need to wake the
thread on failure.
However the thread doesn't perform certain actions when there is any
active plug, so it is important to install a plug before waking the
thread.  So for RAID5 we install the plug *before* queuing the request
and waking the thread.

Without this patch it is possible for raid1 or raid10 to queue a
request without then waking the thread, resulting in the array locking
up.

Also change raid10 to only flush_pending_write when there are not
active plugs, just like raid1.

This patch is suitable for 3.0 or later.  I plan to submit it to
-stable, but I'll like to let it spend a few weeks in mainline
first to be sure it is completely safe.

Signed-off-by: NeilBrown

md: support re-add of recovering devices.

2012-07-03T05:59:06+00:00

We currently only allow a device to be re-added if it appear to be
in-sync.  This is overly restrictive as it may be desirable to re-add
a device that is in the middle of recovery.

So remove the test for "InSync" - the test on rdev->raid_disk is
sufficient to ensure that the re-add will succeed.

Reported-by: Alexander Lyakas 
Tested-by: Alexander Lyakas 
Signed-off-by: NeilBrown

md/raid1: fix bug in read_balance introduced by hot-replace

2012-07-03T05:58:42+00:00

When we added hot_replace we doubled the number of devices
that could be in a RAID1 array.  So we doubled how far read_balance
would search.  Unfortunately we didn't double the point at which
it looped back to the beginning - so it effectively loops over
all non-replacement disks twice.
This doesn't cause bad behaviour, but it pointless and means we
never read from replacement devices.

Signed-off-by: NeilBrown