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

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

dm snapshot: avoid dropping lock in __find_pending_exception

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

upstream commit: c66213921c816f6b1b16a84911618ba9a363b134

It is uncommon and bug-prone to drop a lock in a function that is called with
the lock held, so this is moved to the caller.

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

dm snapshot: refactor __find_pending_exception

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

upstream commit: 2913808eb56a6445a7b277eb8d17651c8defb035

Move looking-up of a pending exception from __find_pending_exception to another
function.

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

dm io: make sync_io uninterruptible

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

upstream commit: b64b6bf4fd8b678a9f8477c11773c38a0a246a6d

If someone sends signal to a process performing synchronous dm-io call,
the kernel may crash.

The function sync_io attempts to exit with -EINTR if it has pending signal,
however the structure "io" is allocated on stack, so already submitted io
requests end up touching unallocated stack space and corrupting kernel memory.

sync_io sets its state to TASK_UNINTERRUPTIBLE, so the signal can't break out
of io_schedule() --- however, if the signal was pending before sync_io entered
while (1) loop, the corruption of kernel memory will happen.

There is no way to cancel in-progress IOs, so the best solution is to ignore
signals at this point.

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

dm raid1: switch read_record from kmalloc to slab to save memory

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

upstream commit: 95f8fac8dc6139fedfb87746e0c8fda9b803cb46

With my previous patch to save bi_io_vec, the size of dm_raid1_read_record
is significantly increased (the vector list takes 3072 bytes on 32-bit machines
and 4096 bytes on 64-bit machines).

The structure dm_raid1_read_record used to be allocated with kmalloc,
but kmalloc aligns the size on the next power-of-two so an object
slightly greater than 4096 will allocate 8192 bytes of memory and half of
that memory will be wasted.

This patch turns kmalloc into a slab cache which doesn't have this
padding so it will reduce the memory consumed.

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