kernel/drivers/md, branch linux-3.3.y

md: Avoid OOPS when reshaping raid1 to raid0

2012-06-01T07:15:55Z

commit 24b961f811a3e790a9b93604d2594bfb6cce4fa4 upstream. raid1 arrays do not have the notion of chunk size. Calculate the largest chunk sector size we can use to avoid a divide by zero OOPS when aligning the size of the new array to the chunk size. Signed-off-by: Jes Sorensen Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman

md: using GFP_NOIO to allocate bio for flush request

2012-06-01T07:15:46Z

commit b5e1b8cee7ad58a15d2fa79bcd7946acb592602d upstream. A flush request is usually issued in transaction commit code path, so using GFP_KERNEL to allocate memory for flush request bio falls into the classic deadlock issue. This is suitable for any -stable kernel to which it applies as it avoids a possible deadlock. Signed-off-by: Shaohua Li Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman

MD: Add del_timer_sync to mddev_suspend (fix nasty panic)

2012-05-21T17:46:22Z

commit 0d9f4f135eb6dea06bdcb7065b1e4ff78274a5e9 upstream. Use del_timer_sync to remove timer before mddev_suspend finishes. We don't want a timer going off after an mddev_suspend is called. This is especially true with device-mapper, since it can call the destructor function immediately following a suspend. This results in the removal (kfree) of the structures upon which the timer depends - resulting in a very ugly panic. Therefore, we add a del_timer_sync to mddev_suspend to prevent this. Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman

dm mpath: check if scsi_dh module already loaded before trying to load

2012-05-21T17:46:21Z

commit 510193a2d3d2e03ae53b95c0ae4f33cdff02cbf8 upstream. If the requested scsi_dh module is already loaded then skip request_module(). Multipath table loads can hang in an unnecessary __request_module. Reported-by: Ben Marzinski Signed-off-by: Mike Snitzer Signed-off-by: Alasdair G Kergon Signed-off-by: Greg Kroah-Hartman

md/raid5: Fix a bug about judging if the operation is syncing or replacing

2012-05-07T15:53:36Z

commit c6d2e084c7411f61f2b446d94989e5aaf9879b0f upstream. When create a raid5 using assume-clean and echo check or repair to sync_action.Then component disks did not operated IO but the raid check/resync faster than normal. Because the judgement in function analyse_stripe(): if (do_recovery || sh->sector >= conf->mddev->recovery_cp) s->syncing = 1; else s->replacing = 1; When check or repair,the recovery_cp == MaxSectore,so syncing equal zero not one. This bug was introduced by commit 9a3e1101b827 md/raid5: detect and handle replacements during recovery. so this patch is suitable for 3.3-stable. Signed-off-by: majianpeng Signed-off-by: NeilBrown Cc: Jes Sorensen Signed-off-by: Greg Kroah-Hartman

md: fix possible corruption of array metadata on shutdown.

2012-04-27T17:16:49Z

commit 30b8aa9172dfeaac6d77897c67ee9f9fc574cdbb upstream. commit c744a65c1e2d59acc54333ce8 md: don't set md arrays to readonly on shutdown. removed the possibility of a 'BUG' when data is written to an array that has just been switched to read-only, but also introduced the possibility that the array metadata could be corrupted. If, when md_notify_reboot gets the mddev lock, the array is in a state where it is assembled but hasn't been started (as can happen if the personality module is not available, or in other unusual situations), then incorrect metadata will be written out making it impossible to re-assemble the array. So only call __md_stop_writes() if the array has actually been activated. This patch is needed for any stable kernel which has had the above commit applied. Reported-by: Christoph Nelles Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman

md: don't call ->add_disk unless there is good reason.

2012-04-27T17:16:49Z

commit ed209584c38fb74b7eecc03e5b1bfe674e591bd8 upstream. Commit 7bfec5f35c68121e7b18 md/raid5: If there is a spare and a want_replacement device, start replacement. cause md_check_recovery to call ->add_disk much more often. Instead of only when the array is degraded, it is now called whenever md_check_recovery finds anything useful to do, which includes updating the metadata for clean<->dirty transition. This causes unnecessary work, and causes info messages from ->add_disk to be reported much too often. So refine md_check_recovery to only do any actual recovery checking (including ->add_disk) if MD_RECOVERY_NEEDED is set. This fix is suitable for 3.3.y: Reported-by: Jan Ceuleers Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman

md/bitmap: prevent bitmap_daemon_work running while initialising bitmap

2012-04-22T22:38:55Z

commit afbaa90b80b1ec66e5137cc3824746bfdf559b18 upstream. If a bitmap is added while the array is active, it is possible for bitmap_daemon_work to run while the bitmap is being initialised. This is particularly a problem if bitmap_daemon_work sees bitmap->filemap as non-NULL before it has been filled in properly. So hold bitmap_info.mutex while filling in ->filemap to prevent problems. This patch is suitable for any -stable kernel, though it might not apply cleanly before about 3.1. Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman

md/raid1,raid10: Fix calculation of 'vcnt' when processing error recovery.

2012-04-22T22:38:55Z

commit f4380a915823dbed0bf8e3cf502ebcf2b7c7f833 upstream. If r1bio->sectors % 8 != 0,then the memcmp and a later memcpy will omit the last bio_vec. This is suitable for any stable kernel since 3.1 when bad-block management was introduced. Signed-off-by: majianpeng Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman

dm thin: fix stacked bi_next usage

2012-04-02T17:32:21Z

commit 6f94a4c45a6f744383f9f695dde019998db3df55 upstream. Avoid using the bi_next field for the holder of a cell when deferring bios because a stacked device below might change it. Store the holder in a new field in struct cell instead. When a cell is created, the bio that triggered creation (the holder) was added to the same bio list as subsequent bios. In some cases we pass this holder bio directly to devices underneath. If those devices use the bi_next field there will be trouble... This also simplifies some code that had to work out which bio was the holder. Signed-off-by: Joe Thornber Signed-off-by: Mike Snitzer Signed-off-by: Alasdair G Kergon Signed-off-by: Greg Kroah-Hartman