| Message ID | 20200916230410.34FCE6074F@lion.mk-sys.cz |
|---|---|
| State | New |
| Headers | show |
| Series | [net] ethtool: add and use message type for tunnel info reply | expand |
On Thu, 17 Sep 2020 01:04:10 +0200 (CEST) Michal Kubecek wrote: > Tunnel offload info code uses ETHTOOL_MSG_TUNNEL_INFO_GET message type (cmd > field in genetlink header) for replies to tunnel info netlink request, i.e. > the same value as the request have. This is a problem because we are using > two separate enums for userspace to kernel and kernel to userspace message > types so that this ETHTOOL_MSG_TUNNEL_INFO_GET (28) collides with > ETHTOOL_MSG_CABLE_TEST_TDR_NTF which is what message type 28 means for > kernel to userspace messages. > > As the tunnel info request reached mainline in 5.9 merge window, we should > still be able to fix the reply message type without breaking backward > compatibility. > > Fixes: c7d759eb7b12 ("ethtool: add tunnel info interface") > Signed-off-by: Michal Kubecek <mkubecek@suse.cz> Ouch, sorry & thanks! Reviewed-by: Jakub Kicinski <kuba@kernel.org>
On Thu, Sep 17, 2020 at 01:04:10AM +0200, Michal Kubecek wrote: > Tunnel offload info code uses ETHTOOL_MSG_TUNNEL_INFO_GET message type (cmd > field in genetlink header) for replies to tunnel info netlink request, i.e. > the same value as the request have. This is a problem because we are using > two separate enums for userspace to kernel and kernel to userspace message > types so that this ETHTOOL_MSG_TUNNEL_INFO_GET (28) collides with > ETHTOOL_MSG_CABLE_TEST_TDR_NTF which is what message type 28 means for > kernel to userspace messages. > > rskb = ethnl_reply_init(reply_len, req_info.dev, > - ETHTOOL_MSG_TUNNEL_INFO_GET, > + ETHTOOL_MSG_TUNNEL_INFO_GET_REPLY, > ETHTOOL_A_TUNNEL_INFO_HEADER, > info, &reply_payload); Michal Maybe it would make sense to change the two enums from anonymous to tagged. We can then make ethnl_reply_init() do type checking and hopefully catch such problems earlier? I just wonder if we then run into ABI problems? Andrew
On Thu, Sep 17, 2020 at 03:41:51AM +0200, Andrew Lunn wrote: > On Thu, Sep 17, 2020 at 01:04:10AM +0200, Michal Kubecek wrote: > > Tunnel offload info code uses ETHTOOL_MSG_TUNNEL_INFO_GET message type (cmd > > field in genetlink header) for replies to tunnel info netlink request, i.e. > > the same value as the request have. This is a problem because we are using > > two separate enums for userspace to kernel and kernel to userspace message > > types so that this ETHTOOL_MSG_TUNNEL_INFO_GET (28) collides with > > ETHTOOL_MSG_CABLE_TEST_TDR_NTF which is what message type 28 means for > > kernel to userspace messages. > > > > > rskb = ethnl_reply_init(reply_len, req_info.dev, > > - ETHTOOL_MSG_TUNNEL_INFO_GET, > > + ETHTOOL_MSG_TUNNEL_INFO_GET_REPLY, > > ETHTOOL_A_TUNNEL_INFO_HEADER, > > info, &reply_payload); > > Michal > > Maybe it would make sense to change the two enums from anonymous to > tagged. We can then make ethnl_reply_init() do type checking and > hopefully catch such problems earlier? This sounds like a good idea, it should prevent similar mistakes. > I just wonder if we then run into ABI problems? I don't think there would be a problem with ABI, binary representation of the values shouldn't change and ethnl_reply_init() is not even exported; ethtool_notify() which would also benefit from stricter type checking is exported but it is still kernel API which is not guaranteed to be stable. On the other hand, the enums are part of userspace API so I better take a closer look to make sure we don't run into some trouble there. Michal
> On the other hand, the enums are part of userspace API so I better take > a closer look to make sure we don't run into some trouble there. Hi Michal Yes, that is what i was thinking about. But i guess you can pass a tagged enum to a function expecting an int and the compiler will silently cast it. Which is what we should have at the moment. So i'm expecting it to be O.K. Andrew
From: Michal Kubecek <mkubecek@suse.cz> Date: Thu, 17 Sep 2020 01:04:10 +0200 (CEST) > Tunnel offload info code uses ETHTOOL_MSG_TUNNEL_INFO_GET message type (cmd > field in genetlink header) for replies to tunnel info netlink request, i.e. > the same value as the request have. This is a problem because we are using > two separate enums for userspace to kernel and kernel to userspace message > types so that this ETHTOOL_MSG_TUNNEL_INFO_GET (28) collides with > ETHTOOL_MSG_CABLE_TEST_TDR_NTF which is what message type 28 means for > kernel to userspace messages. > > As the tunnel info request reached mainline in 5.9 merge window, we should > still be able to fix the reply message type without breaking backward > compatibility. > > Fixes: c7d759eb7b12 ("ethtool: add tunnel info interface") > Signed-off-by: Michal Kubecek <mkubecek@suse.cz> Applied, thank you.
diff --git a/Documentation/networking/ethtool-netlink.rst b/Documentation/networking/ethtool-netlink.rst index d53bcb31645a..b5a79881551f 100644 --- a/Documentation/networking/ethtool-netlink.rst +++ b/Documentation/networking/ethtool-netlink.rst @@ -206,6 +206,7 @@ Userspace to kernel: ``ETHTOOL_MSG_TSINFO_GET`` get timestamping info ``ETHTOOL_MSG_CABLE_TEST_ACT`` action start cable test ``ETHTOOL_MSG_CABLE_TEST_TDR_ACT`` action start raw TDR cable test + ``ETHTOOL_MSG_TUNNEL_INFO_GET`` get tunnel offload info ===================================== ================================ Kernel to userspace: @@ -239,6 +240,7 @@ Kernel to userspace: ``ETHTOOL_MSG_TSINFO_GET_REPLY`` timestamping info ``ETHTOOL_MSG_CABLE_TEST_NTF`` Cable test results ``ETHTOOL_MSG_CABLE_TEST_TDR_NTF`` Cable test TDR results + ``ETHTOOL_MSG_TUNNEL_INFO_GET_REPLY`` tunnel offload info ===================================== ================================= ``GET`` requests are sent by userspace applications to retrieve device @@ -1363,4 +1365,5 @@ are netlink only. ``ETHTOOL_SFECPARAM`` n/a n/a ''ETHTOOL_MSG_CABLE_TEST_ACT'' n/a ''ETHTOOL_MSG_CABLE_TEST_TDR_ACT'' + n/a ``ETHTOOL_MSG_TUNNEL_INFO_GET`` =================================== ===================================== diff --git a/include/uapi/linux/ethtool_netlink.h b/include/uapi/linux/ethtool_netlink.h index 5dcd24cb33ea..72ba36be9655 100644 --- a/include/uapi/linux/ethtool_netlink.h +++ b/include/uapi/linux/ethtool_netlink.h @@ -79,6 +79,7 @@ enum { ETHTOOL_MSG_TSINFO_GET_REPLY, ETHTOOL_MSG_CABLE_TEST_NTF, ETHTOOL_MSG_CABLE_TEST_TDR_NTF, + ETHTOOL_MSG_TUNNEL_INFO_GET_REPLY, /* add new constants above here */ __ETHTOOL_MSG_KERNEL_CNT, diff --git a/net/ethtool/tunnels.c b/net/ethtool/tunnels.c index 84f23289475b..d93bf2da0f34 100644 --- a/net/ethtool/tunnels.c +++ b/net/ethtool/tunnels.c @@ -200,7 +200,7 @@ int ethnl_tunnel_info_doit(struct sk_buff *skb, struct genl_info *info) reply_len = ret + ethnl_reply_header_size(); rskb = ethnl_reply_init(reply_len, req_info.dev, - ETHTOOL_MSG_TUNNEL_INFO_GET, + ETHTOOL_MSG_TUNNEL_INFO_GET_REPLY, ETHTOOL_A_TUNNEL_INFO_HEADER, info, &reply_payload); if (!rskb) { @@ -273,7 +273,7 @@ int ethnl_tunnel_info_dumpit(struct sk_buff *skb, struct netlink_callback *cb) goto cont; ehdr = ethnl_dump_put(skb, cb, - ETHTOOL_MSG_TUNNEL_INFO_GET); + ETHTOOL_MSG_TUNNEL_INFO_GET_REPLY); if (!ehdr) { ret = -EMSGSIZE; goto out;
Tunnel offload info code uses ETHTOOL_MSG_TUNNEL_INFO_GET message type (cmd field in genetlink header) for replies to tunnel info netlink request, i.e. the same value as the request have. This is a problem because we are using two separate enums for userspace to kernel and kernel to userspace message types so that this ETHTOOL_MSG_TUNNEL_INFO_GET (28) collides with ETHTOOL_MSG_CABLE_TEST_TDR_NTF which is what message type 28 means for kernel to userspace messages. As the tunnel info request reached mainline in 5.9 merge window, we should still be able to fix the reply message type without breaking backward compatibility. Fixes: c7d759eb7b12 ("ethtool: add tunnel info interface") Signed-off-by: Michal Kubecek <mkubecek@suse.cz> --- Documentation/networking/ethtool-netlink.rst | 3 +++ include/uapi/linux/ethtool_netlink.h | 1 + net/ethtool/tunnels.c | 4 ++-- 3 files changed, 6 insertions(+), 2 deletions(-)