| Message ID | 20240216113147.50797-1-jiri@resnulli.us (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | [net-next] devlink: fix port dump cmd type | expand |
On Fri, Feb 16, 2024 at 12:31:47PM +0100, Jiri Pirko wrote: > From: Jiri Pirko <jiri@nvidia.com> > > Unlike other commands, due to a c&p error, port dump fills-up cmd with > wrong value, different from port-get request cmd, port-get doit reply > and port notification. > > Fix it by filling cmd with value DEVLINK_CMD_PORT_NEW. > > Skimmed through devlink userspace implementations, none of them cares > about this cmd value. Only ynl, for which, this is actually a fix, as it > expects doit and dumpit ops rsp_value to be the same. I guess that in theory unknown implementations could exist. But, ok :) > > Omit the fixes tag, even thought this is fix, better to target this for > next release. > > Signed-off-by: Jiri Pirko <jiri@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org>
On Mon, 19 Feb 2024 15:13:43 +0000 Simon Horman wrote: > > Fix it by filling cmd with value DEVLINK_CMD_PORT_NEW. > > > > Skimmed through devlink userspace implementations, none of them cares > > about this cmd value. Only ynl, for which, this is actually a fix, as it > > expects doit and dumpit ops rsp_value to be the same. > > I guess that in theory unknown implementations could exist. > But, ok :) I'd also prefer Fixes tag + net. YNL is user space, even if current YNL specs don't trigger it (I'm speculating that that's why you feel it's not a fix) someone may end up using YNL + YAML from 6.9 and expect it to work on 6.6 LTS.
Mon, Feb 19, 2024 at 09:20:38PM CET, kuba@kernel.org wrote: >On Mon, 19 Feb 2024 15:13:43 +0000 Simon Horman wrote: >> > Fix it by filling cmd with value DEVLINK_CMD_PORT_NEW. >> > >> > Skimmed through devlink userspace implementations, none of them cares >> > about this cmd value. Only ynl, for which, this is actually a fix, as it >> > expects doit and dumpit ops rsp_value to be the same. >> >> I guess that in theory unknown implementations could exist. >> But, ok :) > >I'd also prefer Fixes tag + net. YNL is user space, even if current YNL >specs don't trigger it (I'm speculating that that's why you feel it's >not a fix) someone may end up using YNL + YAML from 6.9 and expect it >to work on 6.6 LTS. As you wish. >-- >pw-bot: cr
diff --git a/net/devlink/port.c b/net/devlink/port.c index 78592912f657..4b2d46ccfe48 100644 --- a/net/devlink/port.c +++ b/net/devlink/port.c @@ -583,7 +583,7 @@ devlink_nl_port_get_dump_one(struct sk_buff *msg, struct devlink *devlink, xa_for_each_start(&devlink->ports, port_index, devlink_port, state->idx) { err = devlink_nl_port_fill(msg, devlink_port, - DEVLINK_CMD_NEW, + DEVLINK_CMD_PORT_NEW, NETLINK_CB(cb->skb).portid, cb->nlh->nlmsg_seq, flags, cb->extack);