linux.git/drivers/md, branch v2.6.29

dm crypt: wait for endio to complete before destruction

2009-03-16T17:44:36+00:00

The following oops has been reported when dm-crypt runs over a loop device.

...
[   70.381058] Process loop0 (pid: 4268, ti=cf3b2000 task=cf1cc1f0 task.ti=cf3b2000)
...
[   70.381058] Call Trace:
[   70.381058]  [] ? crypt_dec_pending+0x5e/0x62 [dm_crypt]
[   70.381058]  [] ? crypt_endio+0xa2/0xaa [dm_crypt]
[   70.381058]  [] ? crypt_endio+0x0/0xaa [dm_crypt]
[   70.381058]  [] ? bio_endio+0x2b/0x2e
[   70.381058]  [] ? dec_pending+0x224/0x23b [dm_mod]
[   70.381058]  [] ? clone_endio+0x79/0xa4 [dm_mod]
[   70.381058]  [] ? clone_endio+0x0/0xa4 [dm_mod]
[   70.381058]  [] ? bio_endio+0x2b/0x2e
[   70.381058]  [] ? loop_thread+0x380/0x3b7
[   70.381058]  [] ? do_lo_send_aops+0x0/0x165
[   70.381058]  [] ? autoremove_wake_function+0x0/0x33
[   70.381058]  [] ? loop_thread+0x0/0x3b7

When a table is being replaced, it waits for I/O to complete
before destroying the mempool, but the endio function doesn't
call mempool_free() until after completing the bio.

Fix it by swapping the order of those two operations.

The same problem occurs in dm.c with md referenced after dec_pending.
Again, we swap the order.

Cc: stable@kernel.org
Signed-off-by: Milan Broz 
Signed-off-by: Alasdair G Kergon

dm crypt: fix kcryptd_async_done parameter

2009-03-16T17:44:33+00:00

In the async encryption-complete function (kcryptd_async_done), the
crypto_async_request passed in may be different from the one passed to
crypto_ablkcipher_encrypt/decrypt.  Only crypto_async_request->data is
guaranteed to be same as the one passed in.  The current
kcryptd_async_done uses the passed-in crypto_async_request directly
which may cause the AES-NI-based AES algorithm implementation to panic.

This patch fixes this bug by only using crypto_async_request->data,
which points to dm_crypt_request, the crypto_async_request passed in.
The original data (convert_context) is gotten from dm_crypt_request.

[mbroz@redhat.com: reworked]
Cc: stable@kernel.org
Signed-off-by: Huang Ying 
Cc: Herbert Xu 
Signed-off-by: Milan Broz 
Signed-off-by: Andrew Morton 
Signed-off-by: Alasdair G Kergon

dm io: respect BIO_MAX_PAGES limit

2009-03-16T17:44:30+00:00

dm-io calls bio_get_nr_vecs to get the maximum number of pages to use
for a given device.  It allocates one additional bio_vec to use
internally but failed to respect BIO_MAX_PAGES, so fix this.

This was the likely cause of:
  https://bugzilla.redhat.com/show_bug.cgi?id=173153

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

dm table: rework reference counting fix

2009-03-16T17:44:26+00:00

Fix an error introduced in dm-table-rework-reference-counting.patch.

When there is failure after table initialization, we need to use
dm_table_destroy, not dm_table_put, to free the table.

dm_table_put may be used only after dm_table_get.

Cc: Kiyoshi Ueda 
Signed-off-by: Mikulas Patocka 
Reviewed-by: Jonathan Brassow 
Reviewed-by: Alasdair G Kergon 
Signed-off-by: Alasdair G Kergon

dm ioctl: validate name length when renaming

2009-03-16T16:56:01+00:00

When renaming a mapped device validate the length of the new name.

The rename ioctl accepted any correctly-terminated string enclosed
within the data passed from userspace.  The other ioctls enforce a
size limit of DM_NAME_LEN.  If the name is changed and becomes longer
than that, the device can no longer be addressed by name.

Fix it by properly checking for device name length (including
terminating zero).

Cc: stable@kernel.org
Signed-off-by: Milan Broz 
Reviewed-by: Jonathan Brassow 
Reviewed-by: Alasdair G Kergon 
Signed-off-by: Alasdair G Kergon

md: fix deadlock when stopping arrays

2009-03-04T07:57:25+00:00

Resolve a deadlock when stopping redundant arrays, i.e. ones that
require a call to sysfs_remove_group when shutdown.  The deadlock is
summarized below:

Thread1                Thread2
-------                -------
read sysfs attribute   stop array
                       take mddev lock
                       sysfs_remove_group
sysfs_get_active
wait for mddev lock
                       wait for active

Sysrq-w:
--------
mdmon         S 00000017  2212  4163      1
  f1982ea8 00000046 2dcf6b85 00000017 c0b23100 f2f83ed0 c0b23100 f2f8413c
  c0b23100 c0b23100 c0b1fb98 f2f8413c 00000000 f2f8413c c0b23100 f2291ecc
  00000002 c0b23100 00000000 00000017 f2f83ed0 f1982eac 00000046 c044d9dd
Call Trace:
  [] ? debug_mutex_add_waiter+0x1d/0x58
  [] __mutex_lock_common+0x1d9/0x338
  [] ? __mutex_lock_common+0x1d9/0x338
  [] mutex_lock_interruptible_nested+0x33/0x3a
  [] ? mddev_lock+0x14/0x16
  [] mddev_lock+0x14/0x16
  [] md_attr_show+0x2a/0x49
  [] sysfs_read_file+0x93/0xf9
mdadm         D 00000017  2812  4177      1
  f0401d78 00000046 430456f8 00000017 f0401d58 f0401d20 c0b23100 f2da2c4c
  c0b23100 c0b23100 c0b1fb98 f2da2c4c 0a10fc36 00000000 c0b23100 f0401d70
  00000003 c0b23100 00000000 00000017 f2da29e0 00000001 00000002 00000000
Call Trace:
  [] schedule_timeout+0x1b/0x95
  [] ? schedule_timeout+0x1b/0x95
  [] ? wait_for_common+0x34/0xdc
  [] ? trace_hardirqs_on_caller+0x18/0x145
  [] ? trace_hardirqs_on+0xb/0xd
  [] wait_for_common+0xa0/0xdc
  [] ? default_wake_function+0x0/0x12
  [] wait_for_completion+0x17/0x19
  [] sysfs_addrm_finish+0x19f/0x1d1
  [] sysfs_hash_and_remove+0x42/0x55
  [] sysfs_remove_group+0x57/0x86
  [] do_md_stop+0x13a/0x499

This has been there for a while, but is easier to trigger now that mdmon
is closely watching sysfs.

Cc: 
Reported-by: Jacek Danecki 
Signed-off-by: Dan Williams

md: avoid races when stopping resync.

2009-02-25T02:18:47+00:00

There has been a race in raid10 and raid1 for a long time
which has only recently started showing up due to a scheduler changed.

When a sync_read request finishes, as soon as reschedule_retry
is called, another thread can mark the resync request as having
completed, so md_do_sync can finish, ->stop can be called, and
->conf can be freed.  So using conf after reschedule_retry is not
safe.

Similarly, when finishing a sync_write, calling md_done_sync must be
the last thing we do, as it allows a chain of events which will free
conf and other data structures.

The first of these requires action in raid10.c
The second requires action in raid1.c and raid10.c

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

md/raid10: Don't call bitmap_cond_end_sync when we are doing recovery.

2009-02-25T02:18:47+00:00

For raid1/4/5/6, resync (fixing inconsistencies between devices) is
very similar to recovery (rebuilding a failed device onto a spare).
The both walk through the device addresses in order.

For raid10 it can be quite different.  resync follows the 'array'
address, and makes sure all copies are the same.  Recover walks
through 'device' addresses and recreates each missing block.

The 'bitmap_cond_end_sync' function allows the write-intent-bitmap
(When present) to be updated to reflect a partially completed resync.
It makes assumptions which mean that it does not work correctly for
raid10 recovery at all.

In particularly, it can cause bitmap-directed recovery of a raid10 to
not recovery some of the blocks that need to be recovered.

So move the call to bitmap_cond_end_sync into the resync path, rather
than being in the common "resync or recovery" path.


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

md/raid10: Don't skip more than 1 bitmap-chunk at a time during recovery.

2009-02-25T02:18:47+00:00

When doing recovery on a raid10 with a write-intent bitmap, we only
need to recovery chunks that are flagged in the bitmap.

However if we choose to skip a chunk as it isn't flag, the code
currently skips the whole raid10-chunk, thus it might not recovery
some blocks that need recovering.

This patch fixes it.

In case that is confusing, it might help to understand that there
is a 'raid10 chunk size' which guides how data is distributed across
the devices, and a 'bitmap chunk size' which says how much data
corresponds to a single bit in the bitmap.

This bug only affects cases where the bitmap chunk size is smaller
than the raid10 chunk size.



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

block: fix bad definition of BIO_RW_SYNC

2009-02-18T09:32:00+00:00

We can't OR shift values, so get rid of BIO_RW_SYNC and use BIO_RW_SYNCIO
and BIO_RW_UNPLUG explicitly. This brings back the behaviour from before
213d9417fec62ef4c3675621b9364a667954d4dd.

Signed-off-by: Jens Axboe