David Miller wrote:

From: Andi Kleen <redacted>
Date: Sat, 17 Nov 2007 14:18:46 +0100

  

quoted

Wang Chen [off-list ref] writes:

    

quoted

Herbert Xu said the following on 2007-11-16 12:11:
      

quoted

Wang Chen [off-list ref] wrote:
        

quoted

So, I think the checksum in udp_queue_rcv_skb() actually does
the work, not that in udp_recvmsg() and udp_poll().

If I am wrong, please point out.
          

We may have a bug in the accounting area.  Check the recent
patch made to UDP/IPv6 which is probably needed here as well.

        

Like dave said, decrementing the InDataGrams in this case is an
option.
I will check the same place of UDP/IPv6.
      

And like Benny pointed out it's probably a bad idea because
decrementing counters will be an unexpected ABI change for monitoring 
programs who have no other way to detect overflow.
    

We could defer the increment until we check the checksum,
but that is likely to break even more things because people
(as Wang Chen did initially) will send a packet to some
port with an app that doesn't eat the packets, and expect the
InDatagrams counter to increase once the stack eats the packet.
But it won't until the application does the read.

All of our options suck, we just have to choose the least sucking one
and right now to me that's decrementing the counter as much as I
empathize with the SNMP application overflow detection issue.
More majordomo info at  http://vger.kernel.org/majordomo-info.html
  

You might be able hide the problem by adding some "defered tick logic" 
so that the
counter is monotonic. Kind of like the NTP clock holding hack.