Messages in this thread | | | Subject | Re: Linus BK tree crashes with PANIC: INIT: segmentation violation | From | Derek Atkins <> | Date | 11 Jan 2003 17:19:31 -0500 |
| |
Linus Torvalds <torvalds@transmeta.com> writes:
> > Well, which change-point do you want? Do you want the change-point > > from the string-of-oppses to the "PANIC: INIT: ..."? Or the > > change-point from a working kernel to the string-of-oopses? I already > > computed the latter point. I have not computed the former. > > Well, both are interesting. Nothing says that the problems have to be > related, but it's certainly not inconceivable, and as such both points end > up being interesting. > > > 1) PANIC: INIT: ... > > 2) String of Oopses > > 3) Working Tree. > > > > The changeover from 2-3 is approximately December 30 (see my previous > > post). > > I was hoping for a exact changset, your post didn't seem to be 100% sure.
Ok, I've found the culprit for the "2-3" changepoint (the string-of-oopses). Now that I've figured this one out, I'll go work out the 1-2 changepoint. The string of oopses is a result of the attached ChangeSet (a change to kernel/kallsyms.c:kallsyms_lookup()).
It is quite clearly a problem with the "grab name" loop around line 49. In particular, it appears that "*name" might be a "negative" number which is sending the strncpy() into lala land. Even if you force *name to be unsigned (as a later patch does), it still sign-extends the negative number and you get a HUGE positive number.
I'm trying to find a better way to do this, and I'll try pulling a change forward before I work backwards to search for the 1-2 changepoint. In looking at this patch, I believe that you do NOT need the extra "namebuf" argument -- you just need to handle the loop properly (and return the correct string).
More in a bit...
-derek
ChangeSet@1.914, 2002-12-25 21:46:32-06:00, ak@muc.de kbuild: Stem compression for kallsyms
This patch implements simple stem compression for the kallsyms symbol table. Each symbol has as first byte a count on how many characters are identical to the previous symbol. This compresses the often common repetive prefixes (like subsys_) fairly effectively.
On a fairly full featured monolithic i386 kernel this saves about 60k in the kallsyms symbol table.
The changes are very simple, so the 60k are not shabby.
One visible change is that the caller of kallsyms_lookup has to pass in a buffer now, because it has to be modified. I added an arbitary 127 character limit to it.
Still >210k left in the symbol table unfortunately. Another idea would be to delta encode the addresses in 16bits (functions are all likely to be smaller than 64K). This would especially help on 64bit hosts. Not done yet, however.
No, before someone asks, I don't want to use zlib for that. Far too fragile during an oops and overkill too and it would require to link it into all kernels.
-- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |