Red Hat Bugzilla – Bug 309751
[patch] kernel runs at different offset than compiled start
Last modified: 2008-01-29 00:14:36 EST
Description of problem: The entries in the System.map file don't match the addresses returned by /proc/kallsyms. This also implies that the symbol addresses in vmlinux don't match the symbol addresses in the running kernel. Version-Release number of selected component (if applicable): kernel-2.6.22.5-76.fc7 How reproducible: 100% Steps to Reproduce: 1. grep sys_close /boot/System.map-2.6.22.5-76.fc7 2. grep sys_close /proc/kallsyms 3. notice that they don't match. Actual results: [warlord@pgpdev src]$ grep sys_close /boot/System.map-2.6.22.5-76.fc7 c1079d64 T sys_close c12d0cb4 r __ksymtab_sys_close c12d6a4c r __kcrctab_sys_close c12dc7c3 r __kstrtab_sys_close [warlord@pgpdev src]$ grep sys_close /proc/kallsyms c0479d64 T sys_close c06d0cb4 r __ksymtab_sys_close c06d6a4c r __kcrctab_sys_close c06dc7c3 r __kstrtab_sys_close Expected results: The System.map should match the running kernel and not be "off" by 0x600000 Additional info:
FYI, this seems to be a result of: CONFIG_PHYSICAL_ALIGN=0x400000 CONFIG_PHYSICAL_START=0x1000000 the CONFIG_PHYSICAL_START needs to be <= CONFIG_PHYSICAL_ALIGN in order to get the numbers to work out correctly. The patch to the config would be: - CONFIG_PHYSICAL_START=0x1000000 + CONFIG_PHYSICAL_START=0x400000 Yeah, not a true patch, but it's close enough, right? I've also updated the summary.
There is some reason, probably kdump, that we use the 16MB start.
Roland, is there some reason kdump might need to have physical start at 16MB? Why even have two options?
Well, how about changing the Physical_align to 16MB so they match?
Don't ask me, I just work here. It looks from the history like davej put those settings in the config in December, probably while tweaking with kdump. The kdump documentation suggests 16MB as a canonical thing to use for the kdump kernel when not using relocatable kernels. But we do use relocatable kernels, so AFAIK it really doesn't matter either to kdump or to the regular kernel what the configured address is. Not that I'm the expert on this. I don't know why we don't just leave both these settings with the upstream defaults. Regardless, I don't know why this is really a bug. The kernel is relocatable, so it might have been relocated. Bottom line, the bootloader can do what it pleases and noone really ought to care. Yes, this means that System.map addresses may need a per-boot runtime bias applied, but so it goes. So, I would tend toward the simpler configs that make this not occur in practice, unless there is some reason I don't know about to prefer these settings. But, I would not acknowledge that there is actually any bug here, and I would not warrant that an application can expect the runtime load offset of the kernel to be zero. Instead, any application that is broken by this I would call buggy. All else being equal, there's no reason not to accommodate preexisting bugginess by making the problem not come up now for no other benefit (if indeed there is none). But anyone who experienced a problem with this should take the opportunity now to make their code more robust for future possibilities, given the understanding that runtime load offset is not intended to be a guaranteed constant of the installation.
Roland, Thank you. I agree with what you're saying. In my particular case I'm trying to use kgdb which is a little more brittle, partly because it requires a second system that doesn't have access to the runtime except through a remote serial connection. Also, in practice, the bootloader doesn't really relocate the kernel even though it can, so the fact that it COULD be relocated doesn't really affect what really happens. So, yes, I agree with your "all else being equal" statement, because in my particular case it seems to still work when running with these settings being the same (I've been running with 0x400000 for a while and I've not noticed any issues). Thanks.
Hello, I'm reviewing this bug as part of the kernel bug triage project, an attempt to isolate current bugs in the Fedora kernel. http://fedoraproject.org/wiki/KernelBugTriage Derek, are you still wanting this bug left open? Has the offset been changed since this was raised or your patch accepted?
Hi, Yes, I'd like this bug left open until the patch actually makes it into a released kernel. The two alignments are still different in 2.6.23.9-45.fc7 so I'm still waiting for resolution. Thanks.
Fixed in 2.6.23.14-62
This seems to break booting on x86_64; see https://www.redhat.com/archives/fedora-kernel-list/2008-January/msg00085.html I am currently rebuilding a kernel with this reverted to verify that its the culprit. On x86_64 there is no CONFIG_PHYSICAL_ALIGN so it should not be affected by this bug. (I don't have a box running i386 to verify that it does not cause breakage there) It seems that on x86_64 we need more than 4MB. (and have no reason to change it from 16MB; unless I am missing something).
Confirmed; reverting this change makes my box boot again. Please revert this change on x86_64.
grep sys_close /boot/System.map-2.6.23.12-99.fc8 ffffffff8109b1b0 T sys_close ffffffff8134f5f0 r __ksymtab_sys_close ffffffff8135e6f2 r __kstrtab_sys_close ---- grep sys_close /proc/kallsyms ffffffff8109b1b0 T sys_close ffffffff8134f5f0 r __ksymtab_sys_close ffffffff8135e6f2 r __kstrtab_sys_close seems to match on x86_64; so this change does not fix anything here (was already working as it should; due to CONFIG_PHYSICAL_ALIGN not being present)
kernel-2.6.23.14-64.fc7 has been pushed to the Fedora 7 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update kernel'
kernel-2.6.23.14-64.fc7 has been pushed to the Fedora 7 stable repository. If problems still persist, please make note of it in this bug report.