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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
