Bug 309751 - [patch] kernel runs at different offset than compiled start
[patch] kernel runs at different offset than compiled start
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
7
All Linux
low Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-09-27 15:26 EDT by Derek Atkins
Modified: 2008-01-29 00:14 EST (History)
5 users (show)

See Also:
Fixed In Version: 2.6.23.14-64.fc7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-01-29 00:14:36 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Derek Atkins 2007-09-27 15:26:53 EDT
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:
Comment 1 Derek Atkins 2007-10-01 16:47:17 EDT
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.
Comment 2 Chuck Ebbert 2007-10-29 17:15:53 EDT
There is some reason, probably kdump, that we use the 16MB start.
Comment 3 Chuck Ebbert 2007-10-29 17:17:00 EDT
Roland, is there some reason kdump might need to have physical start at 16MB?
Why even have two options?
Comment 4 Derek Atkins 2007-10-29 17:29:37 EDT
Well, how about changing the Physical_align to 16MB so they match?
Comment 5 Roland McGrath 2007-10-30 03:47:23 EDT
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.
Comment 6 Derek Atkins 2007-10-30 09:53:06 EDT
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.
Comment 7 Christopher Brown 2008-01-14 12:57:09 EST
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?
Comment 8 Derek Atkins 2008-01-14 13:05:15 EST
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.
Comment 9 Chuck Ebbert 2008-01-17 19:14:50 EST
Fixed in 2.6.23.14-62
Comment 10 drago01 2008-01-19 06:28:08 EST
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).
Comment 11 drago01 2008-01-19 06:42:19 EST
Confirmed; reverting this change makes my box boot again.
Please revert this change on x86_64.
Comment 12 drago01 2008-01-19 06:45:19 EST
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)
Comment 13 Fedora Update System 2008-01-24 16:58:27 EST
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'
Comment 14 Fedora Update System 2008-01-29 00:14:32 EST
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.

Note You need to log in before you can comment on or make changes to this bug.