RE: [PATCH v3 2/3] RDMA/mana_ib: Prefer struct_size over open coded arithmetic

[Long Li]

> Subject: [PATCH v3 2/3] RDMA/mana_ib: Prefer struct_size over open coded
> arithmetic
>
> This is an effort to get rid of all multiplications from allocation functions in order to
> prevent integer overflows [1][2].
>
> As the "req" variable is a pointer to "struct mana_cfg_rx_steer_req_v2"
> and this structure ends in a flexible array:
>
> struct mana_cfg_rx_steer_req_v2 {
>       [...]
>         mana_handle_t indir_tab[] __counted_by(num_indir_entries); };
>
> the preferred way in the kernel is to use the struct_size() helper to do the
> arithmetic instead of the calculation "size + size * count" in the kzalloc() function.
>
> Moreover, use the "offsetof" helper to get the indirect table offset instead of the
> "sizeof" operator and avoid the open-coded arithmetic in pointers using the new
> flex member. This new structure member also allow us to remove the
> "req_indir_tab" variable since it is no longer needed.
>
> This way, the code is more readable and safer.
>
> This code was detected with the help of Coccinelle, and audited and modified
> manually.
>
> Link:
> https://www.ker/
> nel.org%2Fdoc%2Fhtml%2Flatest%2Fprocess%2Fdeprecated.html%23open-
> coded-arithmetic-in-allocator-
> arguments&data=05%7C02%7Clongli%40microsoft.com%7Cfcf2a410393a429633
> ca08dc56506b01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63848
> 0150654917952%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQI
> joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=2zSek
> zsyXsS1s9xw%2FwaSEl3h4s6AeiykFG4KiJLzXOc%3D&reserved=0 [1]
> Link:
> https://github.co/
> m%2FKSPP%2Flinux%2Fissues%2F160&data=05%7C02%7Clongli%40microsoft.co
> m%7Cfcf2a410393a429633ca08dc56506b01%7C72f988bf86f141af91ab2d7cd01
> 1db47%7C1%7C0%7C638480150654924997%7CUnknown%7CTWFpbGZsb3d8ey
> JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C
> 0%7C%7C%7C&sdata=4pzQWVWVcIaeS07VgXY1I6%2FS%2FEFejUD4qv1D2Ouwf
> pA%3D&reserved=0 [2]
> Signed-off-by: Erick Archer <erick.archer@xxxxxxxxxxx>

Reviewed-by: Long Li <longli@xxxxxxxxxxxxx>