[iproute PATCH 0/2] Minor vf_info review

While implementing the display of IFLA_VF_QUERY_RSS_EN value in
ip-address (see patch 2/2), I stumbled upon some dubious constructs in
print_vfinfo() and replaced them with code which seems more intuitive to
me (see patch 1/2 for details).

Phil Sutter (2):
  ipaddress: Simplify vf_info parsing
  ipaddress: Print IFLA_VF_QUERY_RSS_EN setting

 ip/ipaddress.c | 52 ++++++++++++++++++----------------------------------
 1 file changed, 18 insertions(+), 34 deletions(-)

-- 
2.8.2

Signed-off-by: Phil Sutter <phil@nwl.cc>
---
 ip/ipaddress.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/ip/ipaddress.c b/ip/ipaddress.c
index 9ac077459f136..bd705dbed60c6 100644
--- a/ip/ipaddress.c
+++ b/ip/ipaddress.c

@@ -364,6 +364,14 @@ static void print_vfinfo(FILE *fp, struct rtattr *vfinfo)
 			fprintf(fp, ", trust %s",
 			        vf_trust->setting ? "on" : "off");
 	}
+	if (vf[IFLA_VF_RSS_QUERY_EN]) {
+		struct ifla_vf_rss_query_en *rss_query =
+			RTA_DATA(vf[IFLA_VF_RSS_QUERY_EN]);
+
+		if (rss_query->setting != -1)
+			fprintf(fp, ", query_rss %s",
+			        rss_query->setting ? "on" : "off");
+	}
 	if (vf[IFLA_VF_STATS] && show_stats)
 		print_vf_stats64(fp, vf[IFLA_VF_STATS]);
 }

-- 
2.8.2

Not sure whether I misinterpret commit 7b8179c780a1a, but it looks
overly complicated. Instead rely upon parse_rtattr_nested() to assign
the relevant pointer if requested rtattr fields are present.

Signed-off-by: Phil Sutter <phil@nwl.cc>
---
 ip/ipaddress.c | 44 ++++++++++----------------------------------
 1 file changed, 10 insertions(+), 34 deletions(-)

diff --git a/ip/ipaddress.c b/ip/ipaddress.c
index df363b070d5de..9ac077459f136 100644
--- a/ip/ipaddress.c
+++ b/ip/ipaddress.c

@@ -305,10 +305,7 @@ static void print_vfinfo(FILE *fp, struct rtattr *vfinfo)
 	struct ifla_vf_mac *vf_mac;
 	struct ifla_vf_vlan *vf_vlan;
 	struct ifla_vf_tx_rate *vf_tx_rate;
-	struct ifla_vf_spoofchk *vf_spoofchk;
-	struct ifla_vf_link_state *vf_linkstate;
 	struct rtattr *vf[IFLA_VF_MAX + 1] = {};
-	struct rtattr *tmp;
 
 	SPRINT_BUF(b1);
 

@@ -323,31 +320,6 @@ static void print_vfinfo(FILE *fp, struct rtattr *vfinfo)
 	vf_vlan = RTA_DATA(vf[IFLA_VF_VLAN]);
 	vf_tx_rate = RTA_DATA(vf[IFLA_VF_TX_RATE]);
 
-	/* Check if the spoof checking vf info type is supported by
-	 * this kernel.
-	 */
-	tmp = (struct rtattr *)((char *)vf[IFLA_VF_TX_RATE] +
-				vf[IFLA_VF_TX_RATE]->rta_len);
-
-	if (tmp->rta_type != IFLA_VF_SPOOFCHK)
-		vf_spoofchk = NULL;
-	else
-		vf_spoofchk = RTA_DATA(vf[IFLA_VF_SPOOFCHK]);
-
-	if (vf_spoofchk) {
-		/* Check if the link state vf info type is supported by
-		 * this kernel.
-		 */
-		tmp = (struct rtattr *)((char *)vf[IFLA_VF_SPOOFCHK] +
-					vf[IFLA_VF_SPOOFCHK]->rta_len);
-
-		if (tmp->rta_type != IFLA_VF_LINK_STATE)
-			vf_linkstate = NULL;
-		else
-			vf_linkstate = RTA_DATA(vf[IFLA_VF_LINK_STATE]);
-	} else
-		vf_linkstate = NULL;
-
 	fprintf(fp, "%s    vf %d MAC %s", _SL_, vf_mac->vf,
 		ll_addr_n2a((unsigned char *)&vf_mac->mac,
 			    ETH_ALEN, 0, b1, sizeof(b1)));

@@ -366,14 +338,18 @@ static void print_vfinfo(FILE *fp, struct rtattr *vfinfo)
 		if (vf_rate->min_tx_rate)
 			fprintf(fp, ", min_tx_rate %dMbps", vf_rate->min_tx_rate);
 	}
+	if (vf[IFLA_VF_SPOOFCHK]) {
+		struct ifla_vf_spoofchk *vf_spoofchk =
+			RTA_DATA(vf[IFLA_VF_SPOOFCHK]);
 
-	if (vf_spoofchk && vf_spoofchk->setting != -1) {
-		if (vf_spoofchk->setting)
-			fprintf(fp, ", spoof checking on");
-		else
-			fprintf(fp, ", spoof checking off");
+		if (vf_spoofchk->setting != -1)
+			fprintf(fp, ", spoof checking %s",
+			        vf_spoofchk->setting ? "on" : "off");
 	}
-	if (vf_linkstate) {
+	if (vf[IFLA_VF_LINK_STATE]) {
+		struct ifla_vf_link_state *vf_linkstate =
+			RTA_DATA(vf[IFLA_VF_LINK_STATE]);
+
 		if (vf_linkstate->link_state == IFLA_VF_LINK_STATE_AUTO)
 			fprintf(fp, ", link-state auto");
 		else if (vf_linkstate->link_state == IFLA_VF_LINK_STATE_ENABLE)

-- 
2.8.2

On Wed, Jun 1, 2016 at 1:03 PM, Phil Sutter [off-list ref] wrote:

Not sure whether I misinterpret commit 7b8179c780a1a, but it looks
overly complicated. Instead rely upon parse_rtattr_nested() to assign
the relevant pointer if requested rtattr fields are present.

I'm not sure if newer iproute2 utilities are supposed to work on older
kernels but if it is you may want to check this against a 2.6.32
kernel.

- Greg Rose

On Wed, Jun 01, 2016 at 03:00:08PM -0700, Greg Rose wrote:

On Wed, Jun 1, 2016 at 1:03 PM, Phil Sutter [off-list ref] wrote:

quoted

Not sure whether I misinterpret commit 7b8179c780a1a, but it looks
overly complicated. Instead rely upon parse_rtattr_nested() to assign
the relevant pointer if requested rtattr fields are present.

I'm not sure if newer iproute2 utilities are supposed to work on older
kernels but if it is you may want to check this against a 2.6.32
kernel.

Yes, it is supposed to. Actually I tried, but the old RHEL6 kernel I
used didn't export the VF list at all and then I lost motivation.

I didn't check all earlier versions of 7b8179c780a1a, was there a stage
when it looked like what I'm changing it to?

Cheers, Phil

On Wed, Jun 1, 2016 at 3:07 PM, Phil Sutter [off-list ref] wrote:

On Wed, Jun 01, 2016 at 03:00:08PM -0700, Greg Rose wrote:

quoted

On Wed, Jun 1, 2016 at 1:03 PM, Phil Sutter [off-list ref] wrote:

quoted

Not sure whether I misinterpret commit 7b8179c780a1a, but it looks
overly complicated. Instead rely upon parse_rtattr_nested() to assign
the relevant pointer if requested rtattr fields are present.

I'm not sure if newer iproute2 utilities are supposed to work on older
kernels but if it is you may want to check this against a 2.6.32
kernel.

Yes, it is supposed to. Actually I tried, but the old RHEL6 kernel I
used didn't export the VF list at all and then I lost motivation.

I didn't check all earlier versions of 7b8179c780a1a, was there a stage
when it looked like what I'm changing it to?

I don't think so but your patch looks correct - I mean it looks like
it should work.

It's been 5 years since I wrote that original patch and my memory
isn't so great as to why I didn't just do as your patch does but I
think it had something to do with not all drivers reporting a spoof
check value.  However, your patch should handle that case so I see no
reason not to accept it.  Unfortunately I don't have time or the
resources at the moment to check it on an older kernel.

- Greg

Cheers, Phil

On Wed, Jun 01, 2016 at 03:36:09PM -0700, Greg Rose wrote:

On Wed, Jun 1, 2016 at 3:07 PM, Phil Sutter [off-list ref] wrote:

quoted

On Wed, Jun 01, 2016 at 03:00:08PM -0700, Greg Rose wrote:

quoted

On Wed, Jun 1, 2016 at 1:03 PM, Phil Sutter [off-list ref] wrote:

quoted

Not sure whether I misinterpret commit 7b8179c780a1a, but it looks
overly complicated. Instead rely upon parse_rtattr_nested() to assign
the relevant pointer if requested rtattr fields are present.

I'm not sure if newer iproute2 utilities are supposed to work on older
kernels but if it is you may want to check this against a 2.6.32
kernel.

Yes, it is supposed to. Actually I tried, but the old RHEL6 kernel I
used didn't export the VF list at all and then I lost motivation.

I didn't check all earlier versions of 7b8179c780a1a, was there a stage
when it looked like what I'm changing it to?

I don't think so but your patch looks correct - I mean it looks like
it should work.

It's been 5 years since I wrote that original patch and my memory
isn't so great as to why I didn't just do as your patch does but I
think it had something to do with not all drivers reporting a spoof
check value.  However, your patch should handle that case so I see no
reason not to accept it.  Unfortunately I don't have time or the
resources at the moment to check it on an older kernel.

So can I count that as your Acked-by? ;)
Looks like Stephen hesitates to accept this patch due to the discussion
it provoked.

Cheers, Phil

On Wed, Jun 01, 2016 at 03:36:09PM -0700, Greg Rose wrote:

On Wed, Jun 1, 2016 at 3:07 PM, Phil Sutter [off-list ref] wrote:

quoted

On Wed, Jun 01, 2016 at 03:00:08PM -0700, Greg Rose wrote:

quoted

On Wed, Jun 1, 2016 at 1:03 PM, Phil Sutter [off-list ref] wrote:

quoted

Not sure whether I misinterpret commit 7b8179c780a1a, but it looks
overly complicated. Instead rely upon parse_rtattr_nested() to assign
the relevant pointer if requested rtattr fields are present.

I'm not sure if newer iproute2 utilities are supposed to work on older
kernels but if it is you may want to check this against a 2.6.32
kernel.

Yes, it is supposed to. Actually I tried, but the old RHEL6 kernel I
used didn't export the VF list at all and then I lost motivation.

I didn't check all earlier versions of 7b8179c780a1a, was there a stage
when it looked like what I'm changing it to?

I don't think so but your patch looks correct - I mean it looks like
it should work.

It's been 5 years since I wrote that original patch and my memory
isn't so great as to why I didn't just do as your patch does but I
think it had something to do with not all drivers reporting a spoof
check value.  However, your patch should handle that case so I see no
reason not to accept it.  Unfortunately I don't have time or the
resources at the moment to check it on an older kernel.

OK, I checked the code and your v1 patch again. Here it is for
reference:

http://www.spinics.net/lists/netdev/msg175377.html

The issue back then was related to the existence of struct ifla_vf_info
which you extended and thus created and incompatibility with older
kernel's headers. This potential problem went away with the introduction
of uapi headers in kernel commit 607ca46e97a1b, as in
include/uapi/linux/if_link.h named structure doesn't even exist anymore.

The netlink interface between kernel and userspace is safe in that
regard: The returned message is merely a list of struct rtattr buffers,
and parse_rtattr_nested() as used in print_vfinfo() iterates over this
list and populates struct rtattr *vf[] with pointers into that buffer.
So in case a given identifier (IFLA_VF_SPOOFCHK in this case) is not
present in the message returned by the kernel, the respective field in
'vf' will just remain a null pointer.

Please note that the above applies to recent kernels as well as older
ones, so the procedure is backward-compatible.

Furthermore, my patch eliminates a potential bug in iproute2 which is
triggered when the kernel at some point decides to not send the
IFLA_VF_SPOOFCHK buffer immediately after IFLA_VF_TX_RATE. This is
perfectly valid in netlink, thus such assumption categorically wrong.

Stephen, please reconsider this patch as it merely aligns print_vfinfo()
with all other places parsing rtnetlink messages, like e.g.
print_linkinfo().

Thanks, Phil

On Wed, Jun 01, 2016 at 10:03:49PM +0200, Phil Sutter wrote:

Not sure whether I misinterpret commit 7b8179c780a1a, but it looks
overly complicated. Instead rely upon parse_rtattr_nested() to assign
the relevant pointer if requested rtattr fields are present.

In order to validate correctness of this patch, I compiled a kernel
which does not export IFLA_VF_SPOOFCHK and verified correct
functionality.

Is there anything else I could do in order to convince you to accept
these patches?

Thanks, Phil