From: NeilBrown <neilb@suse.com>
To: "Bjørnar Ness" <bjornar.ness@gmail.com>, linux-raid@vger.kernel.org
Subject: Re: mdadm segfault with incremental
Date: Mon, 23 Oct 2017 13:12:06 +1100 [thread overview]
Message-ID: <87mv4iehop.fsf@notabene.neil.brown.name> (raw)
In-Reply-To: <CAJO99Tk=at4gXNgEHKmq1=iDip+vt2LT-T8d+FSQYGJquH5C2g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2610 bytes --]
On Thu, Oct 19 2017, Bjørnar Ness wrote:
> While working with mdadm policy/udev to add slaves when they are
> inserted, I notices
> mdadm is segfaulting if it gets a blank drive and action is set to
> spare or above.
>
> Looking into the code, this segfault is caused by the following code:
>
> Incremental.c line 965
>
> st2->ss->avail_size(st2, devsize,
> sra->devs
> ? sra->devs->data_offset
> : INVALID_SECTORS)
>
> avail_size in my case is super1.c avail_size1
>
> and here the code sets:
>
> struct mdp_superblock_1 *super = st->sb;
>
> and later tries accessing i.e super->feature_map, where it segfaults
> because in the case
> of an empty drive, st2 is created in super1.c/match_metadata_desc1
> where it sets:
>
> st->sb = NULL;
>
> I am not entirely sure how this is supposed to work, but atleast
> currently it segfaults.
Hi Bjørnar,
thanks for the report.
This was broken by
Commit: 641da7459192 ("super1: separate to version of _avail_space1().")
in mdadm-3.3. The code in Incremental.c should really be using
->validate_geometry, rather than ->avail_size.
This patch should fix it. Could you please try and report?
Thanks,
NeilBrown
diff --git a/Incremental.c b/Incremental.c
index 91301eb5e609..baea9761cee1 100644
--- a/Incremental.c
+++ b/Incremental.c
@@ -870,7 +870,7 @@ static int array_try_spare(char *devname, int *dfdp, struct dev_policy *pol,
struct supertype *st2;
struct domainlist *dl = NULL;
struct mdinfo *sra;
- unsigned long long devsize;
+ unsigned long long devsize, freesize = 0;
struct spare_criteria sc = {0, 0};
if (is_subarray(mp->metadata))
@@ -942,10 +942,13 @@ static int array_try_spare(char *devname, int *dfdp, struct dev_policy *pol,
close(mdfd);
}
if ((sra->component_size > 0 &&
- st2->ss->avail_size(st2, devsize,
- sra->devs ? sra->devs->data_offset :
- INVALID_SECTORS) <
- sra->component_size) ||
+ st2->ss->validate_geometry(st2, sra->array.level, sra->array.layout,
+ sra->array.raid_disks, &sra->array.chunk_size,
+ sra->component_size,
+ sra->devs ? sra->devs->data_offset : INVALID_SECTORS,
+ devname, &freesize, sra->consistency_policy,
+ 0) &&
+ freesize < sra->component_size) ||
(sra->component_size == 0 && devsize < sc.min_size)) {
if (verbose > 1)
pr_err("not adding %s to %s as it is too small\n",
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
next prev parent reply other threads:[~2017-10-23 2:12 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-19 11:24 mdadm segfault with incremental Bjørnar Ness
2017-10-23 2:12 ` NeilBrown [this message]
2017-10-24 10:30 ` Bjørnar Ness
2017-10-25 22:00 ` NeilBrown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87mv4iehop.fsf@notabene.neil.brown.name \
--to=neilb@suse.com \
--cc=bjornar.ness@gmail.com \
--cc=linux-raid@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.