On Tue, Mar 29 2016, Étienne Buira wrote:
> Sorry, forgot to reply to list as well, resending for completeness.
>
> On Mon, Mar 28, 2016 at 08:19:12AM -0400, Phil Turmel wrote:
>> On 03/28/2016 06:31 AM, Étienne Buira wrote:
>
> ../..
>
>> > 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
>
> Hi,
>
> Thank you for the answer.
>
> I tried to reproduce the case with vanilla 4.4.6, but couldn't enter the
> above said 'if', so i'm giving up on this topic.
>
> However, i'm still surprised that sb->new_offset gets assigned a
> 'negative' (well, high, because it is computed unsigned) value.
>
I guess sb->new_offset should be called sb->delta_offset. If you look
in md_p.h you will see:
__le32 new_offset; /* signed number to add to data_offset in new
* layout. 0 == no-change. This can be
* different on each device in the array.
*/
which goes some way to explaining the situation.
NeilBrown
Attachment:
signature.asc
Description: PGP signature
