linux/drivers/md, branch v3.1

dm kcopyd: fix job_pool leak

2011-10-23T19:55:17Z

Fix memory leak introduced by commit a6e50b409d3f9e0833e69c3c9cca822e8fa4adbb (dm snapshot: skip reading origin when overwriting complete chunk). When allocating a set of jobs from kc->job_pool, job->master_job must be set (to point to itself) so that the mempool item gets freed when the master_job completes. master_job was introduced by commit c6ea41fbbe08f270a8edef99dc369faf809d1bd6 (dm kcopyd: preallocate sub jobs to avoid deadlock) Reported-by: Michael Leun Cc: Mikulas Patocka Signed-off-by: Alasdair G Kergon

Merge branch 'for-linus' of http://people.redhat.com/agk/git/linux-dm

2011-10-06T15:31:47Z

* 'for-linus' of http://people.redhat.com/agk/git/linux-dm: dm crypt: always disable discard_zeroes_data dm: raid fix write_mostly arg validation dm table: avoid crash if integrity profile changes dm: flakey fix corrupt_bio_byte error path

dm crypt: always disable discard_zeroes_data

2011-09-25T22:26:21Z

If optional discard support in dm-crypt is enabled, discards requests bypass the crypt queue and blocks of the underlying device are discarded. For the read path, discarded blocks are handled the same as normal ciphertext blocks, thus decrypted. So if the underlying device announces discarded regions return zeroes, dm-crypt must disable this flag because after decryption there is just random noise instead of zeroes. Signed-off-by: Milan Broz Signed-off-by: Alasdair G Kergon

dm: raid fix write_mostly arg validation

2011-09-25T22:26:19Z

Fix off-by-one error in validation of write_mostly. The user-supplied value given for the 'write_mostly' argument must be an index starting at 0. The validation of the supplied argument failed to check for 'N' ('>' vs '>='), which would have caused an access beyond the end of the array. Reported-by: Doug Ledford Signed-off-by: Jonathan Brassow Signed-off-by: Alasdair G Kergon

dm table: avoid crash if integrity profile changes

2011-09-25T22:26:17Z

Commit a63a5cf (dm: improve block integrity support) introduced a two-phase initialization of a DM device's integrity profile. This patch avoids dereferencing a NULL 'template_disk' pointer in blk_integrity_register() if there is an integrity profile mismatch in dm_table_set_integrity(). This can occur if the integrity profiles for stacked devices in a DM table are changed between the call to dm_table_prealloc_integrity() and dm_table_set_integrity(). Reported-by: Zdenek Kabelac Signed-off-by: Mike Snitzer Signed-off-by: Alasdair G Kergon Cc: stable@kernel.org # 2.6.39

dm: flakey fix corrupt_bio_byte error path

2011-09-25T22:26:15Z

If no arguments were provided to the corrupt_bio_byte feature an error should be returned immediately. Reported-by: Zdenek Kabelac Signed-off-by: Mike Snitzer Signed-off-by: Alasdair G Kergon

md: Avoid waking up a thread after it has been freed.

2011-09-21T05:30:20Z

Two related problems: 1/ some error paths call "md_unregister_thread(mddev->thread)" without subsequently clearing ->thread. A subsequent call to mddev_unlock will try to wake the thread, and crash. 2/ Most calls to md_wakeup_thread are protected against the thread disappeared either by: - holding the ->mutex - having an active request, so something else must be keeping the array active. However mddev_unlock calls md_wakeup_thread after dropping the mutex and without any certainty of an active request, so the ->thread could theoretically disappear. So we need a spinlock to provide some protections. So change md_unregister_thread to take a pointer to the thread pointer, and ensure that it always does the required locking, and clears the pointer properly. Reported-by: "Moshe Melnikov" Signed-off-by: NeilBrown cc: stable@kernel.org

md: Fix handling for devices from 2TB to 4TB in 0.90 metadata.

2011-09-10T07:21:28Z

0.90 metadata uses an unsigned 32bit number to count the number of kilobytes used from each device. This should allow up to 4TB per device. However we multiply this by 2 (to get sectors) before casting to a larger type, so sizes above 2TB get truncated. Also we allow rdev->sectors to be larger than 4TB, so it is possible for the array to be resized larger than the metadata can handle. So make sure rdev->sectors never exceeds 4TB when 0.90 metadata is in used. Also the sanity check at the end of super_90_load should include level 1 as it used ->size too. (RAID0 and Linear don't use ->size at all). Reported-by: Pim Zandbergen Cc: stable@kernel.org Signed-off-by: NeilBrown

md/raid1,10: Remove use-after-free bug in make_request.

2011-09-10T07:21:23Z

A single request to RAID1 or RAID10 might result in multiple requests if there are known bad blocks that need to be avoided. To detect if we need to submit another write request we test: if (sectors_handled < (bio->bi_size >> 9)) { However this is after we call **_write_done() so the 'bio' no longer belongs to us - the writes could have completed and the bio freed. So move the **_write_done call until after the test against bio->bi_size. This addresses https://bugzilla.kernel.org/show_bug.cgi?id=41862 Reported-by: Bruno Wolff III Tested-by: Bruno Wolff III Signed-off-by: NeilBrown

md/raid10: unify handling of write completion.

2011-09-10T07:21:17Z

A write can complete at two different places: 1/ when the last member-device write completes, through raid10_end_write_request 2/ in make_request() when we remove the initial bias from ->remaining. These two should do exactly the same thing and the comment says they do, but they don't. So factor the correct code out into a function and call it in both places. This makes the code much more similar to RAID1. The difference is only significant if there is an error, and they usually take a while, so it is unlikely that there will be an error already when make_request is completing, so this is unlikely to cause real problems. Signed-off-by: NeilBrown