[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <OF03E20988.736A2E51-ON8825737E.007067FE-8825737E.0071B902@us.ibm.com>
Date: Wed, 24 Oct 2007 13:43:14 -0700
From: David Stevens <dlstevens@...ibm.com>
To: Vlad Yasevich <vladislav.yasevich@...com>
Cc: Adrian Bunk <bunk@...nel.org>, linux-kernel@...r.kernel.org,
netdev@...r.kernel.org, netdev-owner@...r.kernel.org
Subject: Re: [2.6 patch] unexport icmpmsg_statistics
My bad -- I see what it's doing, and it looks ok after all.
I thought I saw an INMSGS (but didn't). These are ICMP errors that
went through icmp_rcv() and were counted correctly before getting
to the protocol error handlers. These are failures due mostly to not
having enough, or the right protocol info in the error packet being
handled. I'm not sure I'd count those as ICMP errors, since the
ICMP header itself is correct, but ok...
SCTP doesn't look so bad, though I think the references are
still questionable (but debatable) as ICMP errors.
sctp_v4_err is incrementing ICMP_MIB_INERRORS if there
isn't enough IP header to find the ports, I see. I'm not sure
that counts as an ICMP error, but it's not so terrible.
It's doing the same thing if a lookup fails to match "vtag" from
the encapsulated error packet. Again, I don't know that those
are ICMP errors (which normally are something wrong with
the ICMP header).
So, I stand corrected, and sorry about the histrionics. Since
these are arguably ICMP errors, and since errors is the only
thing being MIB-counted in DCCP and SCTP, then it now looks
ok to me as-is, and also ok to remove icmpmsg_statistics from
exporting.
+-DLS
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists