[iproute,2/2] utils: fix get_rtnl_link_stats_rta stats parsing

Message ID 8b8bb899db6c8ce78d91aa8b192e6c697daf4e27.1539182623.git.lorenzo.bianconi@redhat.com
State Accepted
Delegated to: stephen hemminger
Headers show
Series
  • introduce IFLA_INET6_STATS attribute parsing
Related show

Commit Message

Lorenzo Bianconi Oct. 10, 2018, 3 p.m.
iproute2 walks through the list of available tunnels using netlink
protocol in order to get device info instead of reading
them from proc filesystem. However the kernel reports device statistics
using IFLA_INET6_STATS/IFLA_INET6_ICMP6STATS attributes nested in
IFLA_PROTINFO one but iproutes expects these info in
IFLA_STATS64/IFLA_STATS attributes.
The issue can be triggered with the following reproducer:

$ip link add ip6d0 type ip6tnl mode ip6ip6 local 1111::1 remote 2222::1
$ip -6 -d -s tunnel show ip6d0
ip6d0: ipv6/ipv6 remote 2222::1 local 1111::1 encaplimit 4 hoplimit 64
tclass 0x00 flowlabel 0x00000 (flowinfo 0x00000000)
Dump terminated

Fix the issue introducing IFLA_INET6_STATS attribute parsing

Fixes: 3e953938717f ("iptunnel/ip6tunnel: Use netlink to walk through
tunnels list")

Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
---
 lib/utils.c | 27 +++++++++++++++++++++++++++
 1 file changed, 27 insertions(+)

Comments

Stephen Hemminger Oct. 10, 2018, 7:11 p.m. | #1
On Wed, 10 Oct 2018 17:00:58 +0200
Lorenzo Bianconi <lorenzo.bianconi@redhat.com> wrote:

> iproute2 walks through the list of available tunnels using netlink
> protocol in order to get device info instead of reading
> them from proc filesystem. However the kernel reports device statistics
> using IFLA_INET6_STATS/IFLA_INET6_ICMP6STATS attributes nested in
> IFLA_PROTINFO one but iproutes expects these info in
> IFLA_STATS64/IFLA_STATS attributes.
> The issue can be triggered with the following reproducer:
> 
> $ip link add ip6d0 type ip6tnl mode ip6ip6 local 1111::1 remote 2222::1
> $ip -6 -d -s tunnel show ip6d0
> ip6d0: ipv6/ipv6 remote 2222::1 local 1111::1 encaplimit 4 hoplimit 64
> tclass 0x00 flowlabel 0x00000 (flowinfo 0x00000000)
> Dump terminated
> 
> Fix the issue introducing IFLA_INET6_STATS attribute parsing
> 
> Fixes: 3e953938717f ("iptunnel/ip6tunnel: Use netlink to walk through
> tunnels list")
> 
> Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>

Can't we fix the kernel to report statistics properly, rather than
starting iproute2 doing more /proc interfaces.
Lorenzo Bianconi Oct. 11, 2018, 12:24 p.m. | #2
> > iproute2 walks through the list of available tunnels using netlink
> > protocol in order to get device info instead of reading
> > them from proc filesystem. However the kernel reports device statistics
> > using IFLA_INET6_STATS/IFLA_INET6_ICMP6STATS attributes nested in
> > IFLA_PROTINFO one but iproutes expects these info in
> > IFLA_STATS64/IFLA_STATS attributes.
> > The issue can be triggered with the following reproducer:
> > 
> > $ip link add ip6d0 type ip6tnl mode ip6ip6 local 1111::1 remote 2222::1
> > $ip -6 -d -s tunnel show ip6d0
> > ip6d0: ipv6/ipv6 remote 2222::1 local 1111::1 encaplimit 4 hoplimit 64
> > tclass 0x00 flowlabel 0x00000 (flowinfo 0x00000000)
> > Dump terminated
> > 
> > Fix the issue introducing IFLA_INET6_STATS attribute parsing
> > 
> > Fixes: 3e953938717f ("iptunnel/ip6tunnel: Use netlink to walk through
> > tunnels list")
> > 
> > Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
> 
> Can't we fix the kernel to report statistics properly, rather than
> starting iproute2 doing more /proc interfaces.
> 

Hi Stephen,

sorry, I did not get what you mean. Current iproute implementation
walks through tunnels list using netlink protocol and parses device
statistics in the kernel netlink message. However it does not take
into account the actual netlink message layout since the statistic
attribute is nested in IFLA_PROTINFO one.
Moreover AFAIU the related kernel code has not changed since iproute
commit 3e953938717f, so I guess we should fix the issue in iproute code
instead in the kernel one. Do you agree?

Regards,
Lorenzo
Stephen Hemminger Oct. 11, 2018, 3:09 p.m. | #3
On Thu, 11 Oct 2018 14:24:03 +0200
Lorenzo Bianconi <lorenzo.bianconi@redhat.com> wrote:

> > > iproute2 walks through the list of available tunnels using netlink
> > > protocol in order to get device info instead of reading
> > > them from proc filesystem. However the kernel reports device statistics
> > > using IFLA_INET6_STATS/IFLA_INET6_ICMP6STATS attributes nested in
> > > IFLA_PROTINFO one but iproutes expects these info in
> > > IFLA_STATS64/IFLA_STATS attributes.
> > > The issue can be triggered with the following reproducer:
> > > 
> > > $ip link add ip6d0 type ip6tnl mode ip6ip6 local 1111::1 remote 2222::1
> > > $ip -6 -d -s tunnel show ip6d0
> > > ip6d0: ipv6/ipv6 remote 2222::1 local 1111::1 encaplimit 4 hoplimit 64
> > > tclass 0x00 flowlabel 0x00000 (flowinfo 0x00000000)
> > > Dump terminated
> > > 
> > > Fix the issue introducing IFLA_INET6_STATS attribute parsing
> > > 
> > > Fixes: 3e953938717f ("iptunnel/ip6tunnel: Use netlink to walk through
> > > tunnels list")
> > > 
> > > Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>  
> > 
> > Can't we fix the kernel to report statistics properly, rather than
> > starting iproute2 doing more /proc interfaces.
> >   
> 
> Hi Stephen,

> sorry, I did not get what you mean. Current iproute implementation
> walks through tunnels list using netlink protocol and parses device
> statistics in the kernel netlink message. However it does not take
> into account the actual netlink message layout since the statistic
> attribute is nested in IFLA_PROTINFO one.
> Moreover AFAIU the related kernel code has not changed since iproute
> commit 3e953938717f, so I guess we should fix the issue in iproute code
> instead in the kernel one. Do you agree?
> 
> Regards,
> Lorenzo

Sorry, I was confused and the stats code is really about parsing existing
pile of statistics in netlink.  I thought it was doing /proc version
like nstat already does.

I will reset these patches to under review.
Stephen Hemminger Oct. 15, 2018, 4:41 p.m. | #4
On Thu, 11 Oct 2018 14:24:03 +0200
Lorenzo Bianconi <lorenzo.bianconi@redhat.com> wrote:

> > > iproute2 walks through the list of available tunnels using netlink
> > > protocol in order to get device info instead of reading
> > > them from proc filesystem. However the kernel reports device statistics
> > > using IFLA_INET6_STATS/IFLA_INET6_ICMP6STATS attributes nested in
> > > IFLA_PROTINFO one but iproutes expects these info in
> > > IFLA_STATS64/IFLA_STATS attributes.
> > > The issue can be triggered with the following reproducer:
> > > 
> > > $ip link add ip6d0 type ip6tnl mode ip6ip6 local 1111::1 remote 2222::1
> > > $ip -6 -d -s tunnel show ip6d0
> > > ip6d0: ipv6/ipv6 remote 2222::1 local 1111::1 encaplimit 4 hoplimit 64
> > > tclass 0x00 flowlabel 0x00000 (flowinfo 0x00000000)
> > > Dump terminated
> > > 
> > > Fix the issue introducing IFLA_INET6_STATS attribute parsing
> > > 
> > > Fixes: 3e953938717f ("iptunnel/ip6tunnel: Use netlink to walk through
> > > tunnels list")
> > > 
> > > Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>  
> > 
> > Can't we fix the kernel to report statistics properly, rather than
> > starting iproute2 doing more /proc interfaces.
> >   
> 
> Hi Stephen,
> 
> sorry, I did not get what you mean. Current iproute implementation
> walks through tunnels list using netlink protocol and parses device
> statistics in the kernel netlink message. However it does not take
> into account the actual netlink message layout since the statistic
> attribute is nested in IFLA_PROTINFO one.
> Moreover AFAIU the related kernel code has not changed since iproute
> commit 3e953938717f, so I guess we should fix the issue in iproute code
> instead in the kernel one. Do you agree?
> 
> Regards,
> Lorenzo

Applied to current iproute2.

Patch

diff --git a/lib/utils.c b/lib/utils.c
index e87ecf31..7be2d6be 100644
--- a/lib/utils.c
+++ b/lib/utils.c
@@ -27,6 +27,7 @@ 
 #include <linux/param.h>
 #include <linux/if_arp.h>
 #include <linux/mpls.h>
+#include <linux/snmp.h>
 #include <time.h>
 #include <sys/time.h>
 #include <errno.h>
@@ -1549,6 +1550,24 @@  static void copy_rtnl_link_stats64(struct rtnl_link_stats64 *stats64,
 		*a++ = *b++;
 }
 
+#define IPSTATS_MIB_MAX_LEN	(__IPSTATS_MIB_MAX * sizeof(__u64))
+static void get_snmp_counters(struct rtnl_link_stats64 *stats64,
+			      struct rtattr *s)
+{
+	__u64 *mib = (__u64 *)RTA_DATA(s);
+
+	memset(stats64, 0, sizeof(*stats64));
+
+	stats64->rx_packets = mib[IPSTATS_MIB_INPKTS];
+	stats64->rx_bytes = mib[IPSTATS_MIB_INOCTETS];
+	stats64->tx_packets = mib[IPSTATS_MIB_OUTPKTS];
+	stats64->tx_bytes = mib[IPSTATS_MIB_OUTOCTETS];
+	stats64->rx_errors = mib[IPSTATS_MIB_INDISCARDS];
+	stats64->tx_errors = mib[IPSTATS_MIB_OUTDISCARDS];
+	stats64->multicast = mib[IPSTATS_MIB_INMCASTPKTS];
+	stats64->rx_frame_errors = mib[IPSTATS_MIB_CSUMERRORS];
+}
+
 int get_rtnl_link_stats_rta(struct rtnl_link_stats64 *stats64,
 			    struct rtattr *tb[])
 {
@@ -1565,6 +1584,14 @@  int get_rtnl_link_stats_rta(struct rtnl_link_stats64 *stats64,
 		rta = tb[IFLA_STATS];
 		size = sizeof(struct rtnl_link_stats);
 		s = &stats;
+	} else if (tb[IFLA_PROTINFO]) {
+		struct rtattr *ptb[IPSTATS_MIB_MAX_LEN + 1];
+
+		parse_rtattr_nested(ptb, IPSTATS_MIB_MAX_LEN,
+				    tb[IFLA_PROTINFO]);
+		if (ptb[IFLA_INET6_STATS])
+			get_snmp_counters(stats64, ptb[IFLA_INET6_STATS]);
+		return sizeof(*stats64);
 	} else {
 		return -1;
 	}