netdev - Re: [PATCH] [PATCH net-next] openvswitch: Use correct reply values in datapath and vport ops

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <1539764658.18339.4.camel@klaipeden.com>
Date:   Wed, 17 Oct 2018 17:24:18 +0900
From:   Koichiro Den <den@...ipeden.com>
To:     David Miller <davem@...emloft.net>, pkusunyifeng@...il.com
Cc:     netdev@...r.kernel.org
Subject: Re: [PATCH] [PATCH net-next] openvswitch: Use correct reply values
 in datapath and vport ops

On Sat, 2018-09-29 at 11:44 -0700, David Miller wrote:
> From: Yifeng Sun <pkusunyifeng@...il.com>
> Date: Wed, 26 Sep 2018 11:40:14 -0700
> 
> > This patch fixes the bug that all datapath and vport ops are returning
> > wrong values (OVS_FLOW_CMD_NEW or OVS_DP_CMD_NEW) in their replies.
> > 
> > Signed-off-by: Yifeng Sun <pkusunyifeng@...il.com>
> 
> Applied.

Not directly relating to ovs, but as a similar existing behaviour, we do have
somewhat odd response for CTRL_CMD_GETFAMILY. I mean this part:

diff --git a/net/netlink/genetlink.c b/net/netlink/genetlink.c
index 25eeb6d2a75a..17428d5d1434 100644
--- a/net/netlink/genetlink.c
+++ b/net/netlink/genetlink.c
@@ -789,7 +789,7 @@ static int ctrl_dumpfamily(struct sk_buff *skb, struct
netlink_callback *cb)

                if (ctrl_fill_info(rt, NETLINK_CB(cb->skb).portid,
                                   cb->nlh->nlmsg_seq, NLM_F_MULTI,
-                                  skb, CTRL_CMD_NEWFAMILY) < 0) {
+                                  skb, CTRL_CMD_GETFAMILY) < 0) {
                        n--;
                        break;
                }
@@ -886,7 +886,7 @@ static int ctrl_getfamily(struct sk_buff *skb, struct
genl_info *info)
        }

        msg = ctrl_build_family_msg(res, info->snd_portid, info->snd_seq,
-                                   CTRL_CMD_NEWFAMILY);
+                                   CTRL_CMD_GETFAMILY);
        if (IS_ERR(msg))
                return PTR_ERR(msg);

David, do you think we should retain this existing bahaviour, since this would
be a relatively huge breaking change for userland apps?