Hi,

I'll add the two devname related patches. Applying a multi-patch like that
with everything bungled together obviously doesn't work.

I believe the two relevant upstream patches should solve this problem.

Jes

This should be addressed by mdadm-3.4-11.el7

Applied an additional upstream fix to handle the buffer overrun case.
mdadm-3.4-12.el7 should do the trick now.

Hi,Robert

I use the above command,just reproduced the first and second didn't reprodeced .can you give some more details.


# uname -r
3.10.0-327.el7.x86_64
# rpm -qa | grep mdadm
mdadm-3.3.2-7.el7_2.1.x86_64

# truncate 10G /root/junk
# losetup -f --show /root/junk
/dev/loop0
# mdadm --create /dev/md1048575 --level=1 --raid-devices=2 /dev/loop0 missing
mdadm: /dev/loop0 appears to be part of a raid array:
       level=raid1 devices=2 ctime=Mon Aug 29 03:26:53 2016
mdadm: Note: this array has metadata at the start and
    may not be suitable as a boot device.  If you plan to
    store '/boot' on this device please ensure that
    your boot-loader understands md/v1.x metadata, or use
    --metadata=0.90
Continue creating array? y
mdadm: unexpected failure opening /dev/md1048575


# mdadm --create /dev/md/my_hip_awesome_cool_md_name1 --level=1 --raid-devices=2 /dev/loop0 missing
mdadm: /dev/loop0 appears to be part of a raid array:
       level=raid1 devices=2 ctime=Mon Aug 29 03:26:53 2016
mdadm: Note: this array has metadata at the start and
    may not be suitable as a boot device.  If you plan to
    store '/boot' on this device please ensure that
    your boot-loader understands md/v1.x metadata, or use
    --metadata=0.90
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md/my_hip_awesome_cool_md_name1 started.

I don't understand what additional information is needed. Please expound.

Hi Robert

From your description, below command will be failed, but it passed on my side, could you help check whether I missed something? 

# mdadm --create /dev/md/my_hip_awesome_cool_md_name1 --level=1 --raid-devices=2 /dev/loop0 missing
mdadm: /dev/loop0 appears to be part of a raid array:
       level=raid1 devices=2 ctime=Mon Aug 29 03:26:53 2016
mdadm: Note: this array has metadata at the start and
    may not be suitable as a boot device.  If you plan to
    store '/boot' on this device please ensure that
    your boot-loader understands md/v1.x metadata, or use
    --metadata=0.90
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md/my_hip_awesome_cool_md_name1 started.

Thanks
xiaotzha

I tried both package [1] and [2], step[3] failed with [1][2], and step [4] passed with [1][2].

[1]
mdadm-3.3.2-7.el7_2.1.x86_64
[2]
mdadm-3.4-13.el7
[3]
# mdadm --create /dev/md1048575 --level=1 --raid-devices=2 /dev/loop0 missing
mdadm: /dev/loop0 appears to be part of a raid array:
       level=raid1 devices=2 ctime=Mon Aug 29 03:26:53 2016
mdadm: Note: this array has metadata at the start and
    may not be suitable as a boot device.  If you plan to
    store '/boot' on this device please ensure that
    your boot-loader understands md/v1.x metadata, or use
    --metadata=0.90
Continue creating array? y
mdadm: unexpected failure opening /dev/md1048575

[4]
mdadm --create /dev/md/my_hip_awesome_cool_md_name1 --level=1 --raid-devices=2 /dev/loop0 missing
mdadm: /dev/loop0 appears to be part of a raid array:
       level=raid1 devices=2 ctime=Mon Aug 29 03:26:53 2016
mdadm: Note: this array has metadata at the start and
    may not be suitable as a boot device.  If you plan to
    store '/boot' on this device please ensure that
    your boot-loader understands md/v1.x metadata, or use
    --metadata=0.90
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md/my_hip_awesome_cool_md_name1 started.

But from your "Actual results" description, [3] and [4] should failed with package[1], and pass with package [2].

Now I'm confused with your steps and not sure what's the bug actually fixed?

Could you give more info about it?

Thanks
xiaotzha

OK, I see what is going on here. Before 2e466cce45ac2397ea426a765c829c621901664b, once mdadm decremented from 127 to 0, it would start decrementing from 1048575, but the kernel wouldn't open an md device so I added lines to kill mdadm after creating the dev to make sure it was created correctly even though the kernel would not open it. This made it really easy to test as we could specify an md that would trigger the bug. Now that things are fixed, we have to do it the hard way.

To test 2e466cce45ac2397ea426a765c829c621901664b, we need to make sure that it wraps to md511 after reaching md0 and we can do that by [1]. I believe udev has a race here and it make take two or more tries to actually delete the md devices, hence the while loop.

[1]
for i in {10..138}; do truncate -s 10M /tmp/junk_${i} && \
losetup /dev/loop${i} /tmp/junk_${i} && \
mdadm --create /dev/md/junk${i} --run --level 1 --raid-device=2 \
/dev/loop${i} missing; done
[ -b /dev/md511 ]
GIT_2E466CC=$?
JUNK_MDS=$(for i in $(ls -l /dev/md/junk*); do \
echo ${i} | sed -rn 's|^.*/(md[[:digit:]]+)$|\1|p'; done)
CNT=$(echo $JUNK_MDS | wc -w); while :; do for i in $JUNK_MDS; \
do if [ -b /dev/${i} ]; then mdadm --stop /dev/${i}; ((CNT++)); fi; done; \
if (( $CNT == 0 )); then break 3; else sleep 1; CNT=0; fi; done
for i in {10..138}; do losetup -d /dev/loop${i} && rm -rf /tmp/junk_${i}; done
unset JUNK_MDS
if (( $GIT_2E466CC == 0 )); then echo PASS; else echo FAIL; fi; \
unset GIT_2E466CC

I'm still working on how to test 13db17bd1fcd68b5e5618fcd051ff4137f1ea413, it is taking a long time to trigger the issue.

Reproduced the "mdadm fails to create >128" issue with [1], after create the >128 mds, it would start decrementing from 1048575 and failed.
[1]
mdadm-3.3.2-7.el7_2.1.x86_64
3.10.0-327.41.1.el7.x86_64

Verified with [2], after create the >128 mds, it would start decrementing from 511 and pass, also pass mdadm regression test with [2]
[2]
mdadm-3.4-13.el7.x86_64
3.10.0-509.el7.x86_64


Change to VERIFIED.

Thanks
Yi

To test 13db17bd1fcd68b5e5618fcd051ff4137f1ea413, we have to get the dev minor number above 1<<19 - 1. Using the "CREATE names=yes" option in /etc/mdadm.conf, we start at minor 512, which means we have to create 523,775 md devices on a freshly booted box. Luckily, md doesn't reuse the minor numbers over 511, so we just have to create and stop a single md until we get to the 524287 minor. This will take a few days to run the first time, but will be fast on subsequent tests. (Because this took so long to run, I haven't been able to verify the script will run without issues, so you may have to adjust as needed.)

grep -q "CREATE names=yes" /etc/mdadm.conf
REMOVEMDCREATE=$?
if (( $REMOVEMDCREATE == 1 )); then \
echo "CREATE names=yes" >> /etc/mdadm.conf; fi
truncate -s 10M /tmp/junk
losetup /dev/loop10 /tmp/junk
mdadm --create /dev/md/junk --run --level 1 --raid-devices=2 /dev/loop10 missing
while (( $(ls -lh /dev/md_junk | cut -d' ' -f6) < 524287 )); do \
MINOR=$(ls -lh /dev/md_junk | cut -d' ' -f6); \
echo "minor: ${MINOR}, $((524287-MINOR)) left to go"; \
mdadm --stop /dev/m
d_junk 2>/dev/null; mdadm --create /dev/md/junk --run --level 1 \
--raid-devices=2 /dev/loop10 missing 2>/dev/null; done
mdadm --create /dev/md/junk --run --level 1 --raid-devices=2 /dev/loop10 missing
GIT_13DB17B=$?
if (( GIT_13DB17B == 0 )); then echo "PASS"; else echo "FAIL"; fi; \
unset GIT_13DB17B
if (( $REMOVEMDCREATE == 1 )); then \
sed -i '/CREATE names=yes/d' /etc/mdadm.conf; fi
unset REMOVEMDCREATE

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-2182.html