Re: Probable bug in md with rdev->new_data_offset

[Phil Turmel <philip@turmel.org>]

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