aboutsummaryrefslogtreecommitdiffstats
path: root/arch/Kconfig
diff options
context:
space:
mode:
authorTejun Heo <tj@kernel.org>2009-10-02 13:28:55 +0900
committerTejun Heo <tj@kernel.org>2009-10-02 13:28:55 +0900
commit126b3fcdecd350cad9700908d0ad845084e26a31 (patch)
tree186a166e821bfb85b8434308c1577690aaa91ad4 /arch/Kconfig
parent0efe5e32c8729ef44b00d9a7203e4c99a6378b27 (diff)
downloadkernel_samsung_tuna-126b3fcdecd350cad9700908d0ad845084e26a31.zip
kernel_samsung_tuna-126b3fcdecd350cad9700908d0ad845084e26a31.tar.gz
kernel_samsung_tuna-126b3fcdecd350cad9700908d0ad845084e26a31.tar.bz2
ia64: don't alias VMALLOC_END to vmalloc_end
If CONFIG_VIRTUAL_MEM_MAP is enabled, ia64 defines macro VMALLOC_END as unsigned long variable vmalloc_end which is adjusted to prepare room for vmemmap. This becomes probnlematic if a local variables vmalloc_end is defined in some function (not very unlikely) and VMALLOC_END is used in the function - the function thinks its referencing the global VMALLOC_END value but would be referencing its own local vmalloc_end variable. There's no reason VMALLOC_END should be a macro. Just define it as an unsigned long variable if CONFIG_VIRTUAL_MEM_MAP is set to avoid nasty surprises. Signed-off-by: Tejun Heo <tj@kernel.org> Acked-by: Tony Luck <tony.luck@intel.com> Cc: Fenghua Yu <fenghua.yu@intel.com> Cc: linux-ia64 <linux-ia64@vger.kernel.org> Cc: Christoph Lameter <cl@linux-foundation.org>
Diffstat (limited to 'arch/Kconfig')
0 files changed, 0 insertions, 0 deletions