Re: [PATCH*2] mdadm works with uClibc from SVN

[Nix <nix@esperi.org.uk>]

On 26 Jun 2006, Neil Brown said:
> On Tuesday June 20, nix@esperi.org.uk wrote:
>> For some time, mdadm's been dumping core on me in my uClibc-built
>> initramfs. As you might imagine this is somewhat frustrating, not least
>> since my root filesystem's in LVM on RAID. Half an hour ago I got around
>> to debugging this.
>> 
>> Imagine my surprise when I found that it was effectively guaranteed to
>> crash: map_dev() in util.c is stubbed out for uClibc builds, and
>> returns -1 at all times. That means that code in, among other places,
>> config.c:load_partitions() is guaranteed to segfault, which is a bit
>> tough if you're using the (sane) default `DEVICE partitions' in your
>> mdadm.conf.
> 
> I'm confused.  map_dev doesn't return -1, it returns NULL.

Yes, that was a typo on my part.

> And the code in load_partitions() handles a NULL return.

Er, what?

The code in load_partitions() in mdadm 2.5.1 and below says

,----[ config.c:load_partitions() ]
| name = map_dev(major, minor, 1);
| 
| d = malloc(sizeof(*d));
| d->devname = strdup(name);
`----

So if map_dev() returns NULL, we do a strdup(NULL) -> crash inside
uClibc.

> So I cannot see why it would be core dumping.
> If you have more details, I'd be really interested.

Backtrace (against uClibc compiled with debugging symbols, tested
against a temporary RAID array on a loopback device):

(gdb) run
Starting program: /usr/packages/mdadm/i686-loki/mdadm.uclibc --assemble --uuid=572aeae1:532641bf:49c9aec5:6036454d /dev/md127

Program received signal SIGSEGV, Segmentation fault.
0x080622f8 in strlen (s=0x0) at libc/string/i386/strlen.c:40
40      libc/string/i386/strlen.c: No such file or directory.
        in libc/string/i386/strlen.c
(gdb) bt
#0  0x080622f8 in strlen (s=0x0) at libc/string/i386/strlen.c:40
#1  0x08062d1d in strdup (s1=0x0) at libc/string/strdup.c:30
#2  0x0804b0df in load_partitions () at config.c:247
#3  0x0804b77c in conf_get_devs (conffile=0x0) at config.c:715
#4  0x0804d685 in Assemble (st=0x0, mddev=0xbf9c753e "/dev/md127", mdfd=6, ident=0xbf9c630c, conffile=0x0, devlist=0x0, backup_file=0x0, readonly=0, runstop=0, update=0x0, homehost=0x0,
    verbose=0, force=0) at Assemble.c:184
#5  0x08049d62 in main (argc=4, argv=0xbf9c6514) at mdadm.c:958
(gdb) frame 2
#2  0x0804b0df in load_partitions () at config.c:247
247                     d->devname = strdup(name);
(gdb) info locals
name = 0x0
mp = 0xbf9c5a34 "     0    9873360 hda\n"
f = (FILE *) 0x807b018
buf = "   3     0    9873360 hda\n", '\0' <repeats 546 times>, "1\000\000\000\000\000((ÿÿÿ\177\021", '\0' <repeats 15 times>, "\021\000\000\000\231\231\231\031Z]\234¿\000\000(\005ÿÿÿ\177¼\\\234¿ÓU\006\bZ]\234¿\000\000\000\000\n", '\0' <repeats 15 times>, "d^\234¿ÏÈ\004\bX]\234¿\000\000\000\000\n\000\000\000\000\000Linux", '\0' <repeats 60 times>, "loki\000)", '\0' <repeats 43 times>, "\006", '\0' <repeats 15 times>, "2.6.17-s\000\000\000\000à]\234¿ßÉ\005\b|]\234¿ð]\234¿", '\0' <repeats 12 times>...
rv = (mddev_dev_t) 0x0


I hope the bug's more obvious now :)

> That said: utils doesn't handle the case for 'ftw not available' as
> well as it could.  I will fix that.

The __UCLIBC_HAS_FTW__ macro in <features.h> is the right way to do that
for uClibc, as Luca noted.

-- 
`NB: Anyone suggesting that we should say "Tibibytes" instead of
 Terabytes there will be hunted down and brutally slain.
 That is all.' --- Matthew Wilcox
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html