[lkml]   [2003]   [Jan]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] kallsyms off-by-one and sorting
On Thu, Jan 09, 2003 at 06:22:50AM +0000, Hugh Dickins wrote:
> Beware of kksymoops reports on 2.5.55:
> kallsyms was off-by-one, showing the preceding symbol name. For
> example, if best index 0, no string was copied into the namebuf.

Thanks. Wasn't it there before?

> And it seems odd to do stem compression on symbols sorted by value:
> save more space sorting by name. It's harder then to avoid aliases
> for a value; but very few in kernel text, so scrap last_addr check.

Good point, but it works quite well already because prefixes in
source code tend to be clustered (everything in a file called
subsystem_foo etc.). Sorting by name may improve it even more.

Unfortunately these functions are not as performance critical
as previously thought. At least some versions of top read /proc/<pid>/wchan
now and that will always walk the full symbol table for each
address on the stack (in short it is very very costly)

(I guess it would be a good idea to at least make it root readable
only to prevent users from tying up too much cpu time in kernel)

With the strncpy that got added in 2.5.55 it got even more costly,
because due to a stupid definition it will always zero upto 127 bytes.

So the choice would be either to fix top to not do that or
do binary search or some other efficient search method
(the later would prevent sorting by name). Binary search would
make the stem compression more awkward however because it would
need to scan backwards.

Actually best may be to just get rid of /proc/*/wchan again
and keep the lookup symbol function like it is.

As the top incident shows it is just too dangerous to have around.
And having to press the magic keys on the console isn't that bad...



To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:32    [W:0.034 / U:7.228 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site