On 1/19/18 2:02 PM, Stephen Hemminger wrote: > On Thu, 18 Jan 2018 20:42:44 -0800 > David Ahern <dsah...@gmail.com> wrote: > >> On 1/17/18 5:28 AM, Arkadi Sharshevsky wrote: >>> In case of extending the UAPI old packages would break. >>> >>> Signed-off-by: Arkadi Sharshevsky <arka...@mellanox.com> >>> --- >>> devlink/devlink.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/devlink/devlink.c b/devlink/devlink.c >>> index 39cda06..c9d1838 100644 >>> --- a/devlink/devlink.c >>> +++ b/devlink/devlink.c >>> @@ -343,7 +343,7 @@ static int attr_cb(const struct nlattr *attr, void >>> *data) >>> int type; >>> >>> if (mnl_attr_type_valid(attr, DEVLINK_ATTR_MAX) < 0) >>> - return MNL_CB_ERROR; >>> + return MNL_CB_OK; >>> >>> type = mnl_attr_get_type(attr); >>> if (mnl_attr_validate(attr, devlink_policy[type]) < 0) >>> >> >> What's the point of calling mnl_attr_type_valid if you disregard a >> failure? you might as well not call mnl_attr_type_valid at all. > > The way mnl handles attributes, you have to have a callback and it is up > to the callback to copy the values it wants. The idea is that old code > running against a newer kernel will have a smaller array of attributes > it wants, and only copy those. >
mnl_attr_type_valid calls mnl_attr_get_type which does attr->nla_type & NLA_TYPE_MASK. Since you are no longer acknowledging the return code of mnl_attr_type_valid, you don't care about its checks so you might as well not call it. I don't see anything in libmnl that checks that mnl_attr_type_valid is invoked on an attr, so hence my question -- given the change above why call it all?
