[PATCH] UBUNTU: SAUCE: disable_nx should not be in __cpuinitdata section for X86_32
stefan.bader at canonical.com
Thu Mar 29 15:21:48 UTC 2012
On 29.03.2012 17:09, Tim Gardner wrote:
> On 03/29/2012 08:50 AM, Stefan Bader wrote:
>> On 29.03.2012 15:27, Tim Gardner wrote:
>>> BugLink: http://bugs.launchpad.net/bugs/968233
>>> 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 at I-love.SAKURA.ne.jp>
>>> Signed-off-by: Tim Gardner <tim.gardner at 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;
>>> /* * noexec = on|off
>> Hm, maybe I just understand the annotation incorrectly. But I
>> thought it marks functions and variables as only used during init.
>> Which is wrong on 32bit, but why is it then still considered needed
>> on 64bit? Probably not even needed if this is solely used for nx
> The code in load_elf_binary() that references disable_nx is "#ifdef
> CONFIG_X86_32", so its unused in 64 bit.
My question probably should have been: is an #else required? Which I can answer
myself: yes. So the remaining question just is: would it hurt to just make that
a normal (not __cpuinitdata) variable in all cases? Beside of "wasting" one int.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 900 bytes
Desc: OpenPGP digital signature
More information about the kernel-team