On 03/28/2016 06:31 AM, Étienne Buira wrote:

Hi all,

Please apologise if i hit the wrong list.

This is the right list. :-)

I searched a bit, but could not find bug report or commits that seemed
related, please apologise if i'm wrong here.

I was going to grow a raid6 array (that contained a spare), using this
command:
# mdadm --grow -n 7 /dev/mdx

But when doing so, i got a PAX message saying that a size overflow was
detected in super_1_sync on the decl new_offset. The array was then in
unusable state (presumably because some locks were held).

After printking the values for rdev->new_data_offset and
rdev->data_offset in the
if (rdev->new_data_offset != rdev->data_offset) { ...
block of super_1_sync, i found that new_data_offset (252928 in my case)
where smaller than data_offset (258048), thus, the substraction to
compute sb->new_data_offset yielded an insanely high value.

Modern mdadm and kernels avoid the use of backup files by adjusting the
data offset.  The lowered offset you see is normal.

I suspect the grsecurity kernels haven't kept up with this.  If you can
reproduce a problem with a vanilla kernel, please report back here.
Otherwise you'll have to report to your kernel provider.

Phil
--
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