Description of problem: When compiling a kernel, the linker issues a warning. I'm not sure I even understand the error and recommended fix. Version-Release number of selected component (if applicable): Any linux 3.3 series kernel. How reproducible: Every time. Steps to Reproduce: 1. Configure a kernel using make menuconfig 2. Use rpmbuild to build with the custom configuration 3. Warning occurs in output. Actual results: WARNING: arch/x86/kernel/built-in.o(.data+0x500): Section mismatch in reference from the variable x86_ioapic to the function .init.text:native_ioapic_init_mappings() The variable x86_ioapic references the function __init native_ioapic_init_mappings() If the reference is valid then annotate the variable with __init* or __refdata (see linux/init.h) or name the variable: *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console Expected results: No warning. Additional info: I don't expect any resolution of this, just posting it so there is a note made of it. The 3.3 kernels I've compiled have run fine despite the warning, but this seems like the kind of thing that could create subtle intermittent bugs.
This is coming from the x86-apic_ops-Replace-apic_ops-with-x86_apic_ops.patch we're carrying. It means the x86_ioapic global variable, which is a structure containing a pointer to various ioapic operations, has it's .init member set to native_ioapic_init_mappings. That function is annotated as __init, which means the kernel will discard the memory that function occupies after the init portion of kernel boot is done. It sounds really scary, but I don't think it actually causes a problem in practice as nothing will be calling x86_ioapic.init outside of the very early setup_arch code. Still, it's a valid warning and one that might be better fixed. Konrad, what's the status of this patch upstream and is this warning fixed in a subsequent version of the patch that we have missed?
Thanks for the explanation. I didn't catch all of it, but enough to understand why the kernels worked just fine.
The patches in question were committed to the 3.4 kernel (or some version of them). Closing this out.
Great! Thanks a lot.