| Message ID | 4F7462B7.2010004@canonical.com |
|---|---|
| State | New |
| Headers | show |
Tim Gardner wrote: > This is a multi-part message in MIME format. > > On 03/28/2012 11:47 PM, Tetsuo Handa wrote: > > load_elf_binary() is definitely called after initialization. > > Good catch. This same issue also exists in older kernels where we've > applied the NX emulation patches. OK. Then, I think we also want to fix these warnings probably introduced by commit a6021559 "UBUNTU: SAUCE: (no-up) Modularize vesafb". WARNING: drivers/video/vesafb.o(.exit.text+0x42): Section mismatch in reference from the function vesafb_remove() to the (unknown reference) .init.data:(unknown) The function __exit vesafb_remove() references a (unknown reference) __initdata (unknown). This is often seen when error handling in the exit function uses functionality in the init path. The fix is often to remove the __initdata annotation of (unknown) so it may be used outside an init section. WARNING: drivers/video/vesafb.o(.exit.text+0x4a): Section mismatch in reference from the function vesafb_remove() to the variable .init.data:vesafb_fix The function __exit vesafb_remove() references a variable __initdata vesafb_fix. This is often seen when error handling in the exit function uses functionality in the init path. The fix is often to remove the __initdata annotation of vesafb_fix so it may be used outside an init section. 49 static struct fb_fix_screeninfo vesafb_fix __initdata = { 50 .id = "VESA VGA", 51 .type = FB_TYPE_PACKED_PIXELS, 52 .accel = FB_ACCEL_NONE, 53 }; 527 static int __exit vesafb_remove(struct platform_device *device) 528 { 529 struct fb_info *info = dev_get_drvdata(&device->dev); 530 531 unregister_framebuffer(info); 532 #ifdef CONFIG_MTRR 533 { 534 struct vesafb_info *vfb_info = (struct vesafb_info *) info->par; 535 if (vfb_info->mtrr_hdl >= 0) 536 mtrr_del(vfb_info->mtrr_hdl, 0, 0); 537 } 538 #endif 539 iounmap(info->screen_base); 540 framebuffer_release(info); 541 release_mem_region(vesafb_fix.smem_start, vesafb_fix.smem_len); | | These values are no longer valid upon unloading. 542 543 return 0; 544 }
BugLink: http://bugs.launchpad.net/bugs/969309 I guess I ought to do a more exhaustive audit for these section mismatches. It makes me wonder why we haven't had more problems with section mismatches. rtg
From e540f21852043a4d8e8cf5e505607909d0ab0f51 Mon Sep 17 00:00:00 2001 From: Tim Gardner <tim.gardner@canonical.com> Date: Thu, 29 Mar 2012 06:21:01 -0600 Subject: [PATCH] UBUNTU: SAUCE: disable_nx should not be in __cpuinitdata section for X86_32 I noticed a section mismatch warning while building 3.2.0-20.33 for X86_32. AR arch/x86/lib/lib.a LD vmlinux.o MODPOST vmlinux.o WARNING: vmlinux.o(.text+0x187833): Section mismatch in reference from the function load_elf_binary() to the variable .cpuinit.data:disable_nx The function load_elf_binary() references the variable __cpuinitdata disable_nx. This is often because load_elf_binary lacks a __cpuinitdata annotation or the annotation of disable_nx is wrong. load_elf_binary() is definitely called after initialization. This code was added by 'UBUNTU: ubuntu: nx-emu - i386: NX emulation', so this is not an upstream problem. Reported-by: Tetsuo Handa <from-ubuntu@I-love.SAKURA.ne.jp> Signed-off-by: Tim Gardner <tim.gardner@canonical.com> --- arch/x86/mm/setup_nx.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/x86/mm/setup_nx.c b/arch/x86/mm/setup_nx.c index 90c9eff3..89fd946 100644 --- a/arch/x86/mm/setup_nx.c +++ b/arch/x86/mm/setup_nx.c @@ -6,7 +6,11 @@ #include <asm/pgtable.h> #include <asm/proto.h> +#ifdef CONFIG_X86_32 +int disable_nx; /* referenced by load_elf_binary() */ +#else int disable_nx __cpuinitdata; +#endif /* * noexec = on|off -- 1.7.9.1
On 03/28/2012 11:47 PM, Tetsuo Handa wrote: > load_elf_binary() is definitely called after initialization. Good catch. This same issue also exists in older kernels where we've applied the NX emulation patches. http://bugs.launchpad.net/bugs/968233 rtg