On Thu, Nov 19, 2009 at 02:52:16PM -0500, Neil Horman wrote: > Hey there- > Before anyone flames me for what a oddball solution this is, let me just > say I'm trying to get the ball rolling here. I think there may be better > solutions that can be impemented in reloc_64.S, but I've yet to make any of > the > ones I've tried work successfully. I'm open to suggestions, but this solution > is the only one so far that I've been able to get to work. thanks :) > > > Adjust crcs in __kcrctab_* sections if relocs are used with CONFIG_RELOCATABLE > > When CONFIG_MODVERSIONS and CONFIG_RELOCATABLE are enabled on powerpc > platforms, > kdump has been failing in a rather odd way. specifically modules will not > install. This is because when validating the crcs of symbols that the module > needs, the crc of the module never matches the crc that is stored in the > kernel. > > The underlying cause of this is how CONFIG_MODVERSIONS is implemented, and how > CONFIG_RELOCATABLE are implemented. with CONFIG_MODVERSIONS enabled, for > every > exported symbol in the kernel we emit 2 symbols, __crc_#sym which is declared > extern and __kcrctab_##sym, which is placed in the __kcrctab section of the > binary. The latter has its value set equal to the address of the former > (recalling it is declared extern). After the object file is built, genksyms > is > run on the processed source, and crcs are computed for each exported symbol. > genksyms then emits a linker script which defines each of the needed > __crc_##sym > symbols, and sets their addresses euqal to their respective crcs. This script > is then used in a secondary link to the previously build object file, so that > the crcs of the missing symbol can be validated on module insert. > > The problem here is that because __kcrctab_sym is set equal to &__crc_##sym, a > relocation entry is emitted by the compiler for the __kcrctab__##sym. > Normally > this is not a problem, since relocation on other arches is done without the > aid > of .rel.dyn sections. PPC however uses these relocations when > CONFIG_RELOCATABLE is enabled. nominally, since addressing starts at 0 for > ppc, > its irrelevant, but if we start at a non-zero address (like we do when booting > via kexec from reserved crashkernel memory), the ppc boot code iterates over > the > relocation entries, and winds up adding that relocation offset to all symbols, > including the symbols that are actually the aforementioned crc values in the > __kcrctab_* sections. This effectively corrupts the crcs and prevents any > module loads from happening during a kdump. > > My solution is to 'undo' these relocations prior to boot up. If > ARCH_USES_RELOC_ENTRIES is defined, we add a symbol at address zero to the > linker script for that arch (I call it reloc_start, so that &reloc_start = 0). > This symbol will then indicate the relocation offset for any given boot. We > also add an initcall to the module code that, during boot, scans the > __kcrctab_* > sections and subtracts &reloc_start from every entry in those sections, > restoring the appropriate crc value. > > I've verified that this allows kexec to work properly on ppc64 systems myself. > > Signed-off-by: Neil Horman <nhor...@tuxdriver.com> > Ping, any thoughts here? As I've been mulling this over, I'm beginning to like this solution better than a completely arch-specific section, as this approach makes common the bits that any arch is going to need if they implement CONFIG_RELOCATABLE with a .rel[a].* section set. The alternative is of course to simply skip the appropriate relocations, but thats something that every arch will need to discover on their own. This makes it a bit more clear whats happening I think.
Regards Neil _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
