linux-toradex.git/drivers/md, branch v2.6.29.4

md: fix loading of out-of-date bitmap.

2009-05-18T23:34:33+00:00

commit b74fd2826c5acce20e6f691437b2d19372bc2057 upstream.

When md is loading a bitmap which it knows is out of date, it fills
each page with 1s and writes it back out again.  However the
write_page call makes used of bitmap->file_pages and
bitmap->last_page_size which haven't been set correctly yet.  So this
can sometimes fail.

Move the setting of file_pages and last_page_size to before the call
to write_page.

This bug can cause the assembly on an array to fail, thus making the
data inaccessible.  Hence I think it is a suitable candidate for
-stable.

Reported-by: Vojtech Pavlik 
Signed-off-by: NeilBrown 
Signed-off-by: Greg Kroah-Hartman

md/raid10: don't clear bitmap during recovery if array will still be degraded.

2009-05-18T23:34:32+00:00

commit 18055569127253755d01733f6ecc004ed02f88d0 upstream.

If we have a raid10 with multiple missing devices, and we recover just
one of these to a spare, then we risk (depending on the bitmap and
array chunk size) clearing bits of the bitmap for which recovery isn't
complete (because a device is still missing).

This can lead to a subsequent "re-add" being recovered without
any IO happening, which would result in loss of data.

This patch takes the safe approach of not clearing bitmap bits
if the array will still be degraded.

This patch is suitable for all active -stable kernels.

Cc: stable@kernel.org
Signed-off-by: NeilBrown 
Signed-off-by: Greg Kroah-Hartman

md: fix some (more) errors with bitmaps on devices larger than 2TB.

2009-05-18T23:34:30+00:00

commit db305e507d554430a69ede901a6308e6ecb72349 upstream.

If a write intent bitmap covers more than 2TB, we sometimes work with
values beyond 32bit, so these need to be sector_t.  This patches
add the required casts to some unsigned longs that are being shifted
up.

This will affect any raid10 larger than 2TB, or any raid1/4/5/6 with
member devices that are larger than 2TB.

Signed-off-by: NeilBrown 
Reported-by: "Mario 'BitKoenig' Holbe" 
Signed-off-by: Greg Kroah-Hartman

md: remove ability to explicit set an inactive array to 'clean'.

2009-05-18T23:34:29+00:00

commit 5bf295975416f8e97117bbbcfb0191c00bc3e2b4 upstream.

Being able to write 'clean' to an 'array_state' of an inactive array
to activate it in 'clean' mode is both unnecessary and inconvenient.

It is unnecessary because the same can be achieved by writing
'active'.  This activates and array, but it still remains 'clean'
until the first write.

It is inconvenient because writing 'clean' is more often used to
cause an 'active' array to revert to 'clean' mode (thus blocking
any writes until a 'write-pending' is promoted to 'active').

Allowing 'clean' to both activate an array and mark an active array as
clean can lead to races:  One program writes 'clean' to mark the
active array as clean at the same time as another program writes
'inactive' to deactivate (stop) and active array.  Depending on which
writes first, the array could be deactivated and immediately
reactivated which isn't what was desired.

So just disable the use of 'clean' to activate an array.

This avoids a race that can be triggered with mdadm-3.0 and external
metadata, so it suitable for -stable.

Reported-by: Rafal Marszewski 
Acked-by: Dan Williams 
Signed-off-by: NeilBrown 
Signed-off-by: Greg Kroah-Hartman

dm kcopyd: fix callback race

2009-04-27T17:36:59+00:00

upstream commit: 340cd44451fb0bfa542365e6b4b565bbd44836e2

If the thread calling dm_kcopyd_copy is delayed due to scheduling inside
split_job/segment_complete and the subjobs complete before the loop in
split_job completes, the kcopyd callback could be invoked from the
thread that called dm_kcopyd_copy instead of the kcopyd workqueue.

dm_kcopyd_copy -> split_job -> segment_complete -> job->fn()

Snapshots depend on the fact that callbacks are called from the singlethreaded
kcopyd workqueue and expect that there is no racing between individual
callbacks. The racing between callbacks can lead to corruption of exception
store and it can also mean that exception store callbacks are called twice
for the same exception - a likely reason for crashes reported inside
pending_complete() / remove_exception().

This patch fixes two problems:

1. job->fn being called from the thread that submitted the job (see above).

- Fix: hand over the completion callback to the kcopyd thread.

2. job->fn(read_err, write_err, job->context); in segment_complete
reports the error of the last subjob, not the union of all errors.

- Fix: pass job->write_err to the callback to report all error bits
  (it is done already in run_complete_job)

Cc: stable@kernel.org
Signed-off-by: Mikulas Patocka 
Signed-off-by: Alasdair G Kergon 
Signed-off-by: Chris Wright

dm kcopyd: prepare for callback race fix

2009-04-27T17:36:59+00:00

upstream commit: 73830857bca6f6c9dbd48e906daea50bea42d676

Use a variable in segment_complete() to point to the dm_kcopyd_client
struct and only release job->pages in run_complete_job() if any are
defined.  These changes are needed by the next patch.

Cc: stable@kernel.org
Signed-off-by: Mikulas Patocka 
Signed-off-by: Alasdair G Kergon 
Signed-off-by: Chris Wright

dm table: fix upgrade mode race

2009-04-27T17:36:57+00:00

upstream commit: 570b9d968bf9b16974252ef7cbce73fa6dac34f3

upgrade_mode() sets bdev to NULL temporarily, and does not have any
locking to exclude anything from seeing that NULL.

In dm_table_any_congested() bdev_get_queue() can dereference that NULL and
cause a reported oops.

Fix this by not changing that field during the mode upgrade.

Cc: stable@kernel.org
Cc: Neil Brown 
Signed-off-by: Alasdair G Kergon 
Signed-off-by: Chris Wright

dm: path selector use module refcount directly

2009-04-27T17:36:57+00:00

upstream commit: aea9058801c0acfa2831af1714da412dfb0018c2

Fix refcount corruption in dm-path-selector

Refcounting with non-atomic ops under shared lock will corrupt the counter
in multi-processor system and may trigger BUG_ON().
Use module refcount.
# same approach as dm-target-use-module-refcount-directly.patch here
# https://www.redhat.com/archives/dm-devel/2008-December/msg00075.html

Typical oops:
  kernel BUG at linux-2.6.29-rc3/drivers/md/dm-path-selector.c:90!
  Pid: 11148, comm: dmsetup Not tainted 2.6.29-rc3-nm #1
  dm_put_path_selector+0x4d/0x61 [dm_multipath]
  Call Trace:
   [] free_priority_group+0x33/0xb3 [dm_multipath]
   [] free_multipath+0x31/0x67 [dm_multipath]
   [] multipath_dtr+0x2d/0x32 [dm_multipath]
   [] dm_table_destroy+0x64/0xd8 [dm_mod]
   [] __unbind+0x46/0x4b [dm_mod]
   [] dm_swap_table+0x60/0x14d [dm_mod]
   [] dev_suspend+0xfd/0x177 [dm_mod]
   [] dm_ctl_ioctl+0x24c/0x29c [dm_mod]
   [] ? get_page_from_freelist+0x49c/0x61d
   [] ? dev_suspend+0x0/0x177 [dm_mod]
   [] vfs_ioctl+0x2a/0x77
   [] do_vfs_ioctl+0x448/0x4a0
   [] sys_ioctl+0x57/0x7a
   [] system_call_fastpath+0x16/0x1b

Cc: stable@kernel.org
Signed-off-by: Jun'ichi Nomura 
Signed-off-by: Alasdair G Kergon 
Signed-off-by: Chris Wright

dm target: use module refcount directly

2009-04-27T17:36:57+00:00

upstream commit: 5642b8a61a15436231adf27b2b1bd96901b623dd

The tt_internal's 'use' field is superfluous: the module's refcount can do
the work properly.  An acceptable side-effect is that this increases the
reference counts reported by 'lsmod'.

Remove the superfluous test when removing a target module.

[Crash possible without this on SMP - agk]

Cc: stable@kernel.org
Signed-off-by: Cheng Renquan 
Signed-off-by: Alasdair G Kergon 
Reviewed-by: Alasdair G Kergon 
Reviewed-by: Jonathan Brassow 
Signed-off-by: Chris Wright

dm snapshot: avoid having two exceptions for the same chunk

2009-04-27T17:36:57+00:00

upstream commit: 35bf659b008e83e725dcd30f542e38461dbb867c

We need to check if the exception was completed after dropping the lock.

After regaining the lock, __find_pending_exception checks if the exception
was already placed into &s->pending hash.

But we don't check if the exception was already completed and placed into
&s->complete hash. If the process waiting in alloc_pending_exception was
delayed at this point because of a scheduling latency and the exception
was meanwhile completed, we'd miss that and allocate another pending
exception for already completed chunk.

It would lead to a situation where two records for the same chunk exist
and potential data corruption because multiple snapshot I/Os to the
affected chunk could be redirected to different locations in the
snapshot.

Cc: stable@kernel.org
Signed-off-by: Mikulas Patocka 
Signed-off-by: Alasdair G Kergon 
Signed-off-by: Chris Wright