https://github.com/nhorman/dropwatch/issues/72 reported recently that some kas reports were matching on odd symbols, and it appeared that it was due to the assumption that /proc/kallsyms was sorted. While its mostly true, its not always true, and that leads to odd behavior. most notably behavior in which the dropwatch kas cache has symbols with huge ranges in them, resulting in the aforementioed matches on incorrect symbols with huge offsets
Fix it by doing a reverse price-is-right search. We iterate over every symbol in proc/kallsyms, looking for the symbol that creates the smallest offset to the pc reported. We then update the cache with that symbol, specifying the symbol addr as the symbol range start, and the offset as its end (which is not guaranteed to be correct). If we get a subsequent drop in the same function, but a later offset, we do the full /proc/kallsyms lookup again, and then update the cache with the new end range.
This should let us do two things:
1) Get a consistently correct symbol lookup in /proc/kallsyms 2) continue to enjoy most of the speedup that the symbol cache provides
us.
https://github.com/nhorman/dropwatch/issues/72 reported recently that some kas reports were matching on odd symbols, and it appeared that it was due to the assumption that /proc/kallsyms was sorted. While its mostly true, its not always true, and that leads to odd behavior. most notably behavior in which the dropwatch kas cache has symbols with huge ranges in them, resulting in the aforementioed matches on incorrect symbols with huge offsets
Fix it by doing a reverse price-is-right search. We iterate over every symbol in proc/kallsyms, looking for the symbol that creates the smallest offset to the pc reported. We then update the cache with that symbol, specifying the symbol addr as the symbol range start, and the offset as its end (which is not guaranteed to be correct). If we get a subsequent drop in the same function, but a later offset, we do the full /proc/kallsyms lookup again, and then update the cache with the new end range.
This should let us do two things:
1) Get a consistently correct symbol lookup in /proc/kallsyms 2) continue to enjoy most of the speedup that the symbol cache provides us.
Signed-of-by: Neil Horman nhorman@tuxdriver.com