lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [day] [month] [year] [list]
Date:   Sat, 06 Jul 2019 16:13:14 +0100
From:   Stephan Diestelhorst <stephan.diestelhorst@...il.com>
To:     linux-kernel@...r.kernel.org
Cc:     mariusz.dabrowski@...el.com, jsorensen@...com
Subject: Regression in mdadm breaks assembling of array

(Off list, please keep me in CC, thx!)
Hi there,

TL;DR:
https://github.com/neilbrown/mdadm/commit611d95290dd41d73bd8f9cc06f7ec293a40b819e
regresses mdadm and does not let me assemble my main drive due to kernel
error

md: invalid array_size 125035870 > default size 125035776

caused by changed reservation size in mdadm, and thus reduced "Usable
Size" being reduced too much (smaller than 0.5 * Array Size).

Full write-up with logs etc here: https://forum.manjaro.org/t/mdadm-issues-live-cd-works-existing-install-breaks-fakeraid-imsm/93613

I chased through both 4.0 mdadm (which works, e.g., from a Live image),
and the new 4.1 version (from Manjaro update), and the same disk in the
same machine works with the older, and refuses to work with the newer
mdadm.

The kernel message suggests that the kernel refuses to assemble the
array, and tracing the computation back through both versions (4.0 and
GIT head 3c9b46cf9ae15a9be98fc47e2080bd9494496246 ) reveals that both
versions end up using the default for reserved space, which is
MPB_SECTOR_CNT + IMSM_RESERVED_SECTORS (the other difference between the
versions is the size computed, but that is hopefully intentional due to
444909385fdaccf961308c4319d7029b82bf8bb1 ).

I understand too little to propose a fix or know why the defaults were
changed, but this is clearly a regression, and the disk works in the
same machine in Windows, and with older Live images.

More log output in the Manjaro forum thread, and I have some more log
output with printf's sprinkled around if necessary.

Happy to help fix this, please have a look :)

Thanks,
  Stephan



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ