[prev in list] [next in list] [prev in thread] [next in thread] 

List:       net-snmp-bugs
Subject:    [ net-snmp-Bugs-3102920 ] Table cache: shared cache reload protection
From:       "SourceForge.net" <noreply () sourceforge ! net>
Date:       2010-11-10 20:24:09
Message-ID: E1PGHDF-0001Ff-W2 () sfs-web-9 ! v29 ! ch3 ! sourceforge ! com
[Download RAW message or body]

Bugs item #3102920, was opened at 2010-11-04 09:35
Message generated for change (Settings changed) made by rstory
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112694&aid=3102920&group_id=12694

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: agent
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By:  (bvassche)
Assigned to: Nobody/Anonymous (nobody)
> Summary: Table cache: shared cache reload protection check is broken

Initial Comment:
Many table implementations in Net-SNMP check whether the cached table data is up to \
date before handling any request via the function netsnmp_cache_is_valid(). This \
function is broken - most of the time it doesn't find the cache and hence incorrectly \
reports that the cache is not up to date. This results in too frequent cache updates. \
This occurs with at least Net-SNMP 5.4.2.1, the current 5.4, 5.5, 5.6 branches and \
                the trunk. Verifying for which tables this happens is possible as \
                follows:
* Apply this patch:

--- orig/net-snmp-5.4.2.1/agent/helpers/cache_handler.c	2007-05-11 18:27:42.000000000 \
                +0200
+++ net-snmp-5.4.2.1/agent/helpers/cache_handler.c	2010-11-04 14:21:31.000000000 \
+0100 @@ -403,6 +403,7 @@ netsnmp_cache_is_valid(netsnmp_agent_req
                        const char* name)
 {
     netsnmp_cache  *cache = netsnmp_cache_reqinfo_extract(reqinfo, name);
+    snmp_log(LOG_INFO, "handler %s: cache == NULL\n", name);
     return (cache && cache->valid);
 }
 
* Start the agent on the command line and redirect its output, e.g. as follows:
LD_LIBRARY_PATH=$PWD/snmplib/.libs:$PWD/agent/.libs:$PWD/agent/helpers/.libs \
agent/.libs/snmpd -f -Lo -Mmibs -c ../net-snmp/snmpd.conf udp:0.0.0.0:1161 2>&1 | tee \
agentlog.txt

* Perform three MIB walks.

* Analyze the output, e.g. as follows:
grep -E 'handler|assert' agentlog.txt | sort | uniq -c | sort -n

* Result:
      3 handler route number: cache == NULL
     18 handler usmDHUserKeyTable: cache == NULL
     30 netsnmp_assert !"cache == valid" failed mibII/ip.c:253 ip_handler()
     33 handler tcpConnectionTable: cache == NULL
     36 handler tcpListenerTable: cache == NULL
     36 handler udp: cache == NULL
     63 handler inetNetToMediaTable: cache == NULL
     75 handler udpEndpointTable: cache == NULL
     99 handler tcp: cache == NULL
    108 handler ip: cache == NULL
    108 handler tcpTable: cache == NULL
    116 handler ifXTable: cache == NULL
    117 handler udpTable: cache == NULL
    138 handler ipAddressTable: cache == NULL
    147 handler ipSystemStatsTable: cache == NULL
    159 handler icmp: cache == NULL
    195 handler ipCidrRouteTable: cache == NULL
    201 handler ifTable: cache == NULL
    234 handler inetCidrRouteTable: cache == NULL

----------------------------------------------------------------------

Comment By: Robert Story (rstory)
Date: 2010-11-10 15:22

Message:
crap.. i had a nice long explanation here that got nuked when i uploaded
the patch file. >:-(

so the shorter version: the is_valid() function is poorly named, as what
it really doing is protecting against reloading a shared cache in the
middle of request processing (e.g. a request for ifIndex.1 and ifName.1,
from ifTable and ifXTable, which share a cache). no extra cache reloading
is done, even if the cache is not 'found' (really, found to be associated
with the request), netsnmp_cache_check_and_reload() is called, which does
the read check against the valid flag and the cache timer. this can be
verified by adding -Dhelper:cache_handler to you snmpd args.

however, using the handler name as the lookup key isn't going to work. It
needs to be something unique to the cache. the attached hack/patch prints
the cache address to a temp sting buffer and uses that. with the patch, the
agent will not check the validity or expiration time of the cache for the
second (or later) handler(s), the preventing a cache reload in the middle
of request processing.

hope that makes sense...


----------------------------------------------------------------------

Comment By:  (bvassche)
Date: 2010-11-09 02:11

Message:
Robert: the problem is that while a cache object is present,
netsnmp_cache_is_valid() fails to find it.

----------------------------------------------------------------------

Comment By: Robert Story (rstory)
Date: 2010-11-08 23:10

Message:
ummm... shouldn't the log for a null cache be conditional on something...
like maybe the cache being null? ;-)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112694&aid=3102920&group_id=12694

------------------------------------------------------------------------------
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book "Blueprint to a 
Billion" shares his insights and actions to help propel your 
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev
_______________________________________________
Net-snmp-bugs mailing list
Net-snmp-bugs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-bugs


[prev in list] [next in list] [prev in thread] [next in thread]