On Thu, Oct 12 2017, Shaohua Li wrote:
> On Thu, Oct 12, 2017 at 02:09:21PM +1100, Neil Brown wrote:
>> On Tue, Oct 10 2017, Shaohua Li wrote:
>>
>> > From: Shaohua Li <shli@xxxxxx>
>> >
>> > If PAGE_SIZE is bigger than 4k, we could read out of the disk boundary. Limit
>> > the read size to the end of disk. Write path already has similar limitation.
>> >
>> > Fix: 8031c3ddc70a(md/bitmap: copy correct data for bitmap super)
>> > Reported-by: Joshua Kinard <kumba@xxxxxxxxxx>
>> > Tested-by: Joshua Kinard <kumba@xxxxxxxxxx>
>> > Cc: Song Liu <songliubraving@xxxxxx>
>> > Signed-off-by: Shaohua Li <shli@xxxxxx>
>>
>> Given that this bug was introduced by
>> Commit: 8031c3ddc70a ("md/bitmap: copy correct data for bitmap super")
>>
>> and that patch is markted:
>>
>> Cc: stable@xxxxxxxxxxxxxxx (4.10+)
>>
>> I think this patch should be tagged "CC: stable" too.
>
> I thought the Fix tag is enough, but I'll add the stable
My experience is that Fixes: sometimes causes patched to go to stable,
but not always. Cc: stable *always* causes the stable team to look at
the patch.
I prefer to keep each having a well defined meaning. Fixes is
documentation about a relationship between commits, Cc:stable is a
statement about the importance of a patch.
Thanks,
Neilbrown
>> However ... that earlier patch looks strange to me.
>> Why is it that "raid5 cache could write bitmap superblock before bitmap superblock is
>> initialized." Can we just get raid5 cache *not* to write the bitmap
>> superblock too early?
>> I think that would better than breaking code that previously worked.
>
> That's the log reply code, which must update superblock and hence bitmap
> superblock, because reply happens very earlier. I agree the reply might still
> have problem with bitmap. We'd better defer reply after the raid is fully
> initialized. Song, any idea?
>
> Thanks,
> Shaohua
> --
> 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
Attachment:
signature.asc
Description: PGP signature
