On Mon, 05 Sep 2011 12:39:55 +0200 Adam Kwolek <adam.kwolek@xxxxxxxxx> wrote:
> Problem was found during reshaping 2 volumes /raid0 and raid5/ in container.
> Sometimes mdmon throws core dump due to NULL pointer exception.
>
> Problem occurs in scenario:
> - managemon: is about spare activation (degraded raid4 volume == raid0 under takeover)
> - managemon: detect level change and signals monitor (manage_member() calls replace_array())
> - monitor: detects transition raid4/5->raid0 and sets a->container to NULL
> to indicate array deactivation
> - managemon : continues his work and tries to activate spare (a->check_degraded is set).
> NULL pointer is passed to metadata handler activate_spare()
> Core dump is generated.
>
> To resolve this situation managemon (after monitor kick) checks again
> a->container pointer to learn if current array is not to be deactivated.
This looks like it might be the same bug as is fixed by
Lukasz Dorau <lukasz.dorau@xxxxxxxxx>
in
Subject: [PATCH] FIX: Mdmon crashes after changing RAID level from 1 to 0
Does that look likely?
Thanks,
NeilBrown
>
> Signed-off-by: Adam Kwolek <adam.kwolek@xxxxxxxxx>
> ---
>
> managemon.c | 6 ++++++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/managemon.c b/managemon.c
> index d020f82..3540dac 100644
> --- a/managemon.c
> +++ b/managemon.c
> @@ -475,6 +475,12 @@ static void manage_member(struct mdstat_ent *mdstat,
> }
> }
>
> + /* we are after monitor kick,
> + * so container field can be cleared - check it again
> + */
> + if (a->container == NULL)
> + return;
> +
> /* We don't check the array while any update is pending, as it
> * might container a change (such as a spare assignment) which
> * could affect our decisions.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
