All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gioh Kim <gi-oh.kim@profitbricks.com>
To: Jes Sorensen <Jes.Sorensen@redhat.com>, linux-raid@vger.kernel.org
Cc: Elmar Gerdes <elmar.gerdes@profitbricks.com>,
	Jinpu Wang <jinpu.wang@profitbricks.com>
Subject: [RFC] super1: error handling for super-block loading
Date: Thu, 12 May 2016 19:38:43 +0200	[thread overview]
Message-ID: <5734BFA3.1070405@profitbricks.com> (raw)

Hi,

I found a segfault of mdadm.
mdadm[59966]: segfault at 5c ip 000000000042c1e1 sp 00007ffe52745390 
error 4 in mdadm[400000+65000]

I disassembled mdadm.

   42c170:       41 55                   push   %r13
   42c172:       49 89 f8                mov    %rdi,%r8
   42c175:       41 54                   push   %r12
   42c177:       49 89 d4                mov    %rdx,%r12
   42c17a:       55                      push   %rbp
   42c17b:       53                      push   %rbx
   42c17c:       48 89 f3                mov    %rsi,%rbx
   42c17f:       48 83 ec 08             sub    $0x8,%rsp
   42c183:       f6 c3 01                test   $0x1,%bl
   42c186:       48 8b 6f 18             mov    0x18(%rdi),%rbp
   42c18a:       44 8b 6e 1c             mov    0x1c(%rsi),%r13d
   42c18e:       48 89 f7                mov    %rsi,%rdi
   42c191:       be 88 01 00 00          mov    $0x188,%esi
   42c196:       0f 85 b8 02 00 00       jne    42c454 <socket@plt+0x29724>
   42c19c:       40 f6 c7 02             test   $0x2,%dil
   42c1a0:       0f 85 c2 02 00 00       jne    42c468 <socket@plt+0x29738>
   42c1a6:       40 f6 c7 04             test   $0x4,%dil
   42c1aa:       0f 85 ce 02 00 00       jne    42c47e <socket@plt+0x2974e>
   42c1b0:       89 f1                   mov    %esi,%ecx
   42c1b2:       31 c0                   xor    %eax,%eax
   42c1b4:       c1 e9 03                shr    $0x3,%ecx
   42c1b7:       40 f6 c6 04             test   $0x4,%sil
   42c1bb:       f3 48 ab                rep stos %rax,%es:(%rdi)
   42c1be:       74 0a                   je     42c1ca <socket@plt+0x2949a>
   42c1c0:       c7 07 00 00 00 00       movl   $0x0,(%rdi)
   42c1c6:       48 83 c7 04             add    $0x4,%rdi
   42c1ca:       40 f6 c6 02             test   $0x2,%sil
   42c1ce:       74 09                   je     42c1d9 <socket@plt+0x294a9>
   42c1d0:       66 c7 07 00 00          movw   $0x0,(%rdi)
   42c1d5:       48 83 c7 02             add    $0x2,%rdi
   42c1d9:       83 e6 01                and    $0x1,%esi
   42c1dc:       74 03                   je     42c1e1 <socket@plt+0x294b1>
   42c1de:       c6 07 00                movb   $0x0,(%rdi)
   42c1e1:       8b 45 5c                mov    0x5c(%rbp),%eax

I think this is getinfo_super1() because I rebuilt mdadm with debugging 
symbol and found exactly the same assemble code.
A NULL pointer referencing is generated by reading st->sb->raid_disks 
(%rdi=st, %rbp=sb=NULL).
I found there is no error handling if Grow_addbitmap fails to load 
super-block.

I'm not sure yet why mdadm failed to load super-block of disks.
I checked the kernel log and found I/O error from disks.
Anyway mdadm needs to handle that error case.

Please review following patch.

------------------------------------------- 8< 
-------------------------------------------------------------
 From 8cacf56b2d630c7e74bad942779ff7ed5f516d26 Mon Sep 17 00:00:00 2001
From: Gioh Kim <gi-oh.kim@profitbricks.com>
Date: Thu, 12 May 2016 19:09:45 +0200
Subject: [PATCH] super1: error handling for super-block loading

Loading super-block can fail if all sub-devices are faulty
or have I/O errors.

Signed-off-by: Gioh Kim <gi-oh.kim@profitbricks.com>
---
  Grow.c | 7 ++++++-
  1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/Grow.c b/Grow.c
index f58c753..fa08522 100755
--- a/Grow.c
+++ b/Grow.c
@@ -389,7 +389,7 @@ int Grow_addbitmap(char *devname, int fd, struct 
context *c, struct shape *s)
      }
      if (strcmp(s->bitmap_file, "internal") == 0 ||
          strcmp(s->bitmap_file, "clustered") == 0) {
-        int rv;
+        int rv = 0;
          int d;
          int offset_setable = 0;
          struct mdinfo *mdi;
@@ -419,6 +419,7 @@ int Grow_addbitmap(char *devname, int fd, struct 
context *c, struct shape *s)
                  if (fd2 < 0)
                      continue;
                  if (st->ss->load_super(st, fd2, NULL)==0) {
+                    rv++;
                      if (st->ss->add_internal_bitmap(
                              st,
                              &s->bitmap_chunk, c->delay, s->write_behind,
@@ -435,6 +436,10 @@ int Grow_addbitmap(char *devname, int fd, struct 
context *c, struct shape *s)
                  close(fd2);
              }
          }
+        if (rv == 0) {
+            pr_err("failed to load super-block.\n");
+            return 1;
+        }
          if (offset_setable) {
              st->ss->getinfo_super(st, mdi, NULL);
              sysfs_init(mdi, fd, NULL);
-- 
2.5.0



             reply	other threads:[~2016-05-12 17:38 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-12 17:38 Gioh Kim [this message]
2016-05-12 18:16 ` [RFC] super1: error handling for super-block loading Jes Sorensen
2016-05-12 19:43   ` Jes Sorensen
2016-05-13 15:15     ` Gioh Kim

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=5734BFA3.1070405@profitbricks.com \
    --to=gi-oh.kim@profitbricks.com \
    --cc=Jes.Sorensen@redhat.com \
    --cc=elmar.gerdes@profitbricks.com \
    --cc=jinpu.wang@profitbricks.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.