In case of extending the UAPI old packages would break.
Signed-off-by: Arkadi Sharshevsky <redacted>
---
devlink/devlink.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: David Ahern <hidden> Date: 2018-01-19 04:42:52
On 1/17/18 5:28 AM, Arkadi Sharshevsky wrote:
quoted hunk
In case of extending the UAPI old packages would break.
Signed-off-by: Arkadi Sharshevsky <redacted>
---
devlink/devlink.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Stephen Hemminger <stephen@networkplumber.org> Date: 2018-01-19 22:02:35
On Thu, 18 Jan 2018 20:42:44 -0800
David Ahern [off-list ref] wrote:
On 1/17/18 5:28 AM, Arkadi Sharshevsky wrote:
quoted
In case of extending the UAPI old packages would break.
Signed-off-by: Arkadi Sharshevsky <redacted>
---
devlink/devlink.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
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.
From: David Ahern <hidden> Date: 2018-01-19 22:27:13
On 1/19/18 2:02 PM, Stephen Hemminger wrote:
On Thu, 18 Jan 2018 20:42:44 -0800
David Ahern [off-list ref] wrote:
quoted
On 1/17/18 5:28 AM, Arkadi Sharshevsky wrote:
quoted
In case of extending the UAPI old packages would break.
Signed-off-by: Arkadi Sharshevsky <redacted>
---
devlink/devlink.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
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?
From: Stephen Hemminger <stephen@networkplumber.org> Date: 2018-01-19 23:40:34
On Fri, 19 Jan 2018 14:27:06 -0800
David Ahern [off-list ref] wrote:
On 1/19/18 2:02 PM, Stephen Hemminger wrote:
quoted
On Thu, 18 Jan 2018 20:42:44 -0800
David Ahern [off-list ref] wrote:
quoted
On 1/17/18 5:28 AM, Arkadi Sharshevsky wrote:
quoted
In case of extending the UAPI old packages would break.
Signed-off-by: Arkadi Sharshevsky <redacted>
---
devlink/devlink.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
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?
The part that matters is:
static int attr_cb(const struct nlattr *attr, void *data)
{
const struct nlattr **tb = data;
int type;
if (mnl_attr_type_valid(attr, DEVLINK_ATTR_MAX) < 0) << makes sure that type < DEVLINK_ATTR_MAX
return MNL_CB_OK;
type = mnl_attr_get_type(attr);
if (mnl_attr_validate(attr, devlink_policy[type]) < 0) << this part doesn't matter really
return MNL_CB_ERROR;
tb[type] = attr; << necessary so that tb[] is filled in.
return MNL_CB_OK;
}
From: David Ahern <hidden> Date: 2018-01-20 00:00:39
On 1/19/18 3:40 PM, Stephen Hemminger wrote:
quoted
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?
ok. I see the error in my thinking.
The part that matters is:
static int attr_cb(const struct nlattr *attr, void *data)
{
const struct nlattr **tb = data;
int type;
if (mnl_attr_type_valid(attr, DEVLINK_ATTR_MAX) < 0) << makes sure that type < DEVLINK_ATTR_MAX
return MNL_CB_OK;
type = mnl_attr_get_type(attr);
if (mnl_attr_validate(attr, devlink_policy[type]) < 0) << this part doesn't matter really
return MNL_CB_ERROR;
tb[type] = attr; << necessary so that tb[] is filled in.
return MNL_CB_OK;
}