We seem to encounter occasional module cache hash collisions. In order to diagnose these better, we should track some more information, such as a log file in ../cache itself to record something about the context & versions. Maybe even log some substrings of the hash.cxx::hash() parameters.
Created attachment 4564 [details] Draft patch Initialize implementation of a simple log file to record every hash operation. ash log file : /home/wjhuang/.systemtap/stap_hash.log [Wed Jan 27 11:13:21 2010]tracequery_hash: 2.6.33-rc5,i386,/lib/modules/2.6.33-rc5/build,/lib/modules/2.6.33-rc5/build/include/trace/syscall.h result:f5608c4e210b53ab1591419c1dd54a88_457 [Wed Jan 27 11:13:28 2010]stapconf_hash: 2.6.33-rc5,i386,/lib/modules/2.6.33-rc5/build result:cb130f7753fed3a69399b43d434e7bce_396 [Wed Jan 27 11:13:28 2010]script_hash: 2.6.33-rc5,i386,-b,-t,'kernel.function("sys_open@fs/open.c:107...' result:95d439ce01faad6a5cb1076009382839_2012
Thanks for the draft. Two ideas to consider: - extending the hash.add() function to pass names along with the hash-mix values, so that class hash can internally track the hash-report string - storing the reports themselves in the cache, beside the .ko / .c files, and changing the cache-size-limit logic to delete these .txt files upon garbage collection
Created attachment 4568 [details] Patch v2 Revamp patch to address frank's concern. 1. Keep all the parameters in hash::add and store them with hash result. 2. The log file will be generated at the end of find_*_hash function, and put at the same directory as *.ko. 3. Update cache-mb-limit so as to remove the log file once cache reaches limitation.
commit 0d1ad607311857dc0b4666ce8a84c1a59c615ab9
committed