Re: "Inconsistent kallsyms data" error

[Jan Beulich]

>>> On 05.07.12 at 23:18, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> Anyway, after hacking the source to actually show the difference, and
> to also *not* change the version string just becuse it's dirty, I see
> this difference:
> 
>  - System.map:
> 
>     ...
>     ffffffff8189b4d0 R kallsyms_addresses
>     ffffffff818ee910 R kallsyms_num_syms
>     ffffffff818ee918 R kallsyms_names
>     ...
>     ffffffff819fa9a0 R __stop___modver
>     ffffffff819fb000 R __end_rodata
>     ...
> 
>  - .tmp_System.map:
> 
>     ...
>     ffffffff8189b4d0 R kallsyms_addresses
>     ffffffff818ee850 R kallsyms_num_syms
>     ffffffff818ee858 R kallsyms_names
>     ...
>     ffffffff819fa720 R __stop___modver
>     ffffffff819fb000 R __end_rodata
> 
> (the diff itself is huge, because once the addresses change, they stay
> different).
> 
> Notice how 'kallsyms_addresses' has the same value, but
> 'kallsyms_num_syms' (and subsequent symbols until the page-aligned
> __end_rodata symbol that gets them back in sync) do not. I have no
> idea *why* this happens, but it definitely does.
> 
> It seems the real difference is the size of the "kallsyms_addresses"
> data structure. No idea why, though.

Since it's clearly not an alignment problem, it almost certainly
means there were symbols added in the second pass, when
none were expected to be added.

> This happens with current git (commit c4aed353b1b0), on an x86-64
> machine running current F17 as of today, with the attached config.
> Maybe that makes somebody else able to recreate this and figure out
> what is so magical about the layout that the exact kernel version and
> config (and likely compiler/binutils versions) matter.
> 
> Any ideas? Added a fairly random set of people who get mentioned in
> the linker script commits etc.

I would have asked you to tar up all files in the build tree root
(if you still have them, ideally including the ones you saved from
deletion; quite possibly other object files in the tree might
subsequently need looking at too, so just taking the full tree
would probably be best), but since I'll be on vacation for two
weeks starting this evening that would probably not be of much
immediate help.

In the unlikely event that the problem remains unsolved till then,
I would still offer to take a look, not the least because the mere
presence of the KALLSYMS_EXTRA_PASS workaround always
puzzled me. (With reproduction unfortunately being so fragile, 
I'm having not much hope to be able to recreate the issue
myself.)

Jan

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/