David Miller wrote:
From: Andi Kleen <[EMAIL PROTECTED]>
Date: Sat, 17 Nov 2007 14:18:46 +0100
Wang Chen <[EMAIL PROTECTED]> writes:
Herbert Xu said the following on 2007-11-16 12:11:
Wang Chen <[EMAIL PROTECTED]> wrote:
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.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
