4.1-stable review patch.  If anyone has any objections, please let me know.

------------------

From: NeilBrown <ne...@suse.de>

commit bd6919228d7e1867ae9e24ab27e3e4a366c87d21 upstream.

If ->private is set when ->run is called, it is assumed to be
a 'config'  prepared as part of 'reshape'.

So it is important when we free that config, that we also clear ->private.
This is not often a problem as the mddev will normally be discarded
shortly after the config us freed.
However if an 'assemble' races with a final close, the assemble can use
the old mddev which has a stale ->private.  This leads to any of
various sorts of crashes.

So clear ->private after calling ->free().

Reported-by: Nate Clark <n...@neworld.us>
Fixes: afa0f557cb15 ("md: rename ->stop to ->free")
Signed-off-by: NeilBrown <ne...@suse.com>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>

---
 drivers/md/md.c |    3 +++
 1 file changed, 3 insertions(+)

--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -5159,6 +5159,7 @@ int md_run(struct mddev *mddev)
                mddev_detach(mddev);
                if (mddev->private)
                        pers->free(mddev, mddev->private);
+               mddev->private = NULL;
                module_put(pers->owner);
                bitmap_destroy(mddev);
                return err;
@@ -5294,6 +5295,7 @@ static void md_clean(struct mddev *mddev
        mddev->changed = 0;
        mddev->degraded = 0;
        mddev->safemode = 0;
+       mddev->private = NULL;
        mddev->merge_check_needed = 0;
        mddev->bitmap_info.offset = 0;
        mddev->bitmap_info.default_offset = 0;
@@ -5366,6 +5368,7 @@ static void __md_stop(struct mddev *mdde
        mddev->pers = NULL;
        spin_unlock(&mddev->lock);
        pers->free(mddev, mddev->private);
+       mddev->private = NULL;
        if (pers->sync_request && mddev->to_remove == NULL)
                mddev->to_remove = &md_redundancy_group;
        module_put(pers->owner);


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to