netdev - RX/dropped counter values for tagged packets

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-next>] [day] [month] [year] [list]

Date:	Sun, 24 Mar 2013 21:43:16 -0700
From:	Ani Sinha <ani@...stanetworks.com>
To:	netdev@...r.kernel.org, linuxdev@...rban.org,
	linux-netdev@...r.kernel.org
Subject: RX/dropped counter values for tagged packets

hello everyone :

Please bear with me if you think I said something wrong.

I was looking at the netif_receive_skb() code and it seems to me that
for vlan tagged packets, the counters are manipulated at two different
places. One is from vlan_do_receive() where the receive counters are
incremented. The other counter (the dropped counter) is incremented at
the very end of netif_receive_skb() when there are no takers for this
packet. The dropped counts are incremented for skb->dev->rx_dropped
whereas the receive counts are incremented for the vlan device
specific private stat counter values. When the numbers are reported on
/proc/net/dev (from where ifconfig gets the numbers), these two stat
counters are combined together (see dev_get_stats() where rx_dropped
is added to the device private stat numbers). So if no one is
receiving the tagged packets, it will be reported both as received and
dropped! I wonder whether I am analyzing it wrong or whether no one
has noticed this before or whether this is intentional.

Any  clarification will be greatly appreciated. Again, I could be
wrong looking at the code, so please bear with me.

Thanks

ani
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html