linux-kernel - Re: "Inconsistent kallsyms data" error

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 06 Jul 2012 08:25:43 +0100
From:	"Jan Beulich" <JBeulich@...e.com>
To:	"Linus Torvalds" <torvalds@...ux-foundation.org>
Cc:	"Nick Bowler" <nbowler@...iptictech.com>,
	"Arnaud Lacombe" <lacombar@...il.com>,
	"Sam Ravnborg" <sam@...nborg.org>, "Michal Marek" <mmarek@...e.cz>,
	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>
Subject: Re: "Inconsistent kallsyms data" error

>>> On 05.07.12 at 23:18, Linus Torvalds <torvalds@...ux-foundation.org> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/