> On Sat, 17 Oct 2020 14:34:11 +0200 Michal Kubecek wrote: > > On Fri, Oct 16, 2020 at 10:02:38AM +0800, zhudi wrote: > > > "ip addr show" command execute error when we have a physical > network > > > card with number of VFs larger than 247. > > > > > > The return value of if_nlmsg_size() in rtnl_calcit() will exceed > > > range of u16 data type when any network cards has a larger number of > > > VFs. rtnl_vfinfo_size() will significant increase needed dump size > > > when the value of num_vfs is larger. > > > > > > Eventually we get a wrong value of min_ifinfo_dump_size because of > > > overflow which decides the memory size needed by netlink dump and > > > netlink_dump() will return -EMSGSIZE because of not enough memory > was allocated. > > > > > > So fix it by promoting min_dump_alloc data type to u32 to avoid > > > data overflow and it's also align with the data type of struct > > > netlink_callback{}.min_dump_alloc which is assigned by return value > > > of rtnl_calcit() > > > > Unfortunately this is only part of the problem. For a NIC with so many > > VFs (not sure if exactly 247 but it's close to that), IFLA_VFINFO_LIST > > nested attribute itself would be over 64KB long which is not possible > > as attribute size is u16. > > > > So we should rather fail in such case (except when IFLA_VFINFO_LIST > > itself fits into 64KB but the whole netlink message would not) and > > provide an alternative way to get information about all VFs. > > Right, we should probably move to devlink as much as possible. > > zhudi, why not use size_t? Seems like the most natural fit for counting size.
Thanks for your replying. min_dump_alloc original type used is u16 and it's eventually assigned to struct netlink_callback{}. min_dump_alloc which data type is u32. So I just simply promote to u32. Should be used size_t instead of u32?