This is a note to let you know that I've just added the patch titled
md/bitmap: ensure to load bitmap when creating via sysfs.
to the 3.3-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
md-bitmap-ensure-to-load-bitmap-when-creating-via-sysfs.patch
and it can be found in the queue-3.3 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <[email protected]> know about it.
>From 4474ca42e2577563a919fd3ed782e2ec55bf11a2 Mon Sep 17 00:00:00 2001
From: NeilBrown <[email protected]>
Date: Mon, 19 Mar 2012 12:46:37 +1100
Subject: md/bitmap: ensure to load bitmap when creating via sysfs.
From: NeilBrown <[email protected]>
commit 4474ca42e2577563a919fd3ed782e2ec55bf11a2 upstream.
When commit 69e51b449d383e (md/bitmap: separate out loading a bitmap...)
created bitmap_load, it missed calling it after bitmap_create when a
bitmap is created through the sysfs interface.
So if a bitmap is added this way, we don't allocate memory properly
and can crash.
This is suitable for any -stable release since 2.6.35.
Signed-off-by: NeilBrown <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/md/bitmap.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/md/bitmap.c
+++ b/drivers/md/bitmap.c
@@ -1904,6 +1904,8 @@ location_store(struct mddev *mddev, cons
if (mddev->pers) {
mddev->pers->quiesce(mddev, 1);
rv = bitmap_create(mddev);
+ if (!rv)
+ rv = bitmap_load(mddev);
if (rv) {
bitmap_destroy(mddev);
mddev->bitmap_info.offset = 0;
Patches currently in stable-queue which might be from [email protected] are
queue-3.3/md-raid1-raid10-avoid-deadlock-during-resync-recovery.patch
queue-3.3/md-bitmap-ensure-to-load-bitmap-when-creating-via-sysfs.patch
queue-3.3/md-fix-clearing-of-the-changed-flags-for-the-bad-blocks-list.patch
queue-3.3/md-don-t-set-md-arrays-to-readonly-on-shutdown.patch
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
