On 10.2.2017 09:59, Shivasharan S wrote: > Change MR_TargetIdToLdGet return type from u8 to u16. > > ld id range check is added at two places in this patch - > @megasas_build_ldio_fusion and @megasas_build_ld_nonrw_fusion. > Previous driver code used different data type for lds TargetId returned from > MR_TargetIdToLdGet. > Prior to this change, above two functions was safeguarded due to function > always return u8 > and maximum value of ld id returned was 255. > > In below check, fw_supported_vd_count as of today is 64 or 256 and > valid range to support is either 0-63 or 0-255. Ideally want to filter > accessing > raid map for ld ids which are not valid. With the u16 change, invalid ld id > value > is 0xFFFF and we will see kernel panic due to random memory access in > MR_LdRaidGet. > The changes will ensure we do not call MR_LdRaidGet if ld id is beyond size > of ldSpanMap array. > > if (ld < instance->fw_supported_vd_count) > > From firmware perspective,ld id 0xFF is invalid and even though current driver > code forward such command, firmware fails with target not available. > > ld target id issue occurs mainly whenever driver loops to populate raid map > (ea. MR_ValidateMapInfo). > These are the only two places where we may see out of range target ids and > wants to > protect raid map access based on range provided by Firmware API. > > Signed-off-by: Shivasharan S <shivasharan.srikanteshw...@broadcom.com> > Signed-off-by: Kashyap Desai <kashyap.de...@broadcom.com>
Reviewed-by: Tomas Henzl <the...@redhat.com> Tomas
