Date:	Fri, 18 Jan 2013 14:24:15 -0600
From:	Matt Sealey <matt@...esi-usa.com>
To:	Linux ARM Kernel ML <linux-arm-kernel@...ts.infradead.org>,
	devel@...verdev.osuosl.org, LKML <linux-kernel@...r.kernel.org>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Seth Jennings <sjenning@...ux.vnet.ibm.com>,
	Nitin Gupta <ngupta@...are.org>,
	Minchan Kim <minchan@...nel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
Subject: Compilation problem with drivers/staging/zsmalloc when !SMP on ARM

Hello all,

I wonder if anyone can shed some light on this linking problem I have
right now. If I configure my kernel without SMP support (it is a very
lean config for i.MX51 with device tree support only) I hit this error
on linking:

  MODPOST 216 modules
  LZMA    arch/arm/boot/compressed/piggy.lzma
  AS      arch/arm/boot/compressed/lib1funcs.o
ERROR: "v7wbi_flush_kern_tlb_range"
[drivers/staging/zsmalloc/zsmalloc.ko] undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2
make: *** Waiting for unfinished jobs....

I am wondering if someone who is far better versed in the mm code can
tell me exactly what would end up calling this function and why it
would only be in the kernel at all if SMP was enabled - all I can see
right now is that it is PROBABLY something resulting from this code
and comment inside the zsmalloc driver:

/*
 * By default, zsmalloc uses a copy-based object mapping method to access
 * allocations that span two pages. However, if a particular architecture
 * 1) Implements local_flush_tlb_kernel_range() and 2) Performs VM mapping
 * faster than copying, then it should be added here so that
 * USE_PGTABLE_MAPPING is defined. This causes zsmalloc to use page table
 * mapping rather than copying
 * for object mapping.
*/
#if defined(CONFIG_ARM)
#define USE_PGTABLE_MAPPING
#endif

And of course, once USE_PGTABLE_MAPPING is enabled,
local_flush_tlb_kernel_range being used is the actual culprit here.

But the question is, for the ARM guys, shouldn't
local_flush_tlb_kernel_range actually be defined in the kernel build,
even without SMP, even if it would be architecturally a no-op on UP
systems, and then CONFIG_SMP_ON_UP would catch this case?

If not, then the fix is obvious, the check inside zsmalloc for
CONFIG_ARM should be fixed to check specifically for
local_flush_tlb_kernel_range definition as well, or for CONFIG_SMP as
well, or the non-presence of CONFIG_SMP_ON_UP or something?

The build cases I have tested are basically CONFIG_SMP +
CONFIG_SMP_ON_UP (since it's a single-core Cortex-A8) and without
CONFIG_SMP (since it's a Cortex-A8..) using imx_v7_defconfig and
imx_v6_v7_defconfig alike and making the appropriate adjustments.
Trying to compile it with CONFIG_SMP without CONFIG_SMP_ON_UP makes no
sense on my target system - but essentially it only links with
CONFIG_SMP.

I got no clue what I am looking at in arch/arm/mm and related, so I am
unsure precisely how I should proceed in patching it with the intent
it goes upstream.. or what the real implication of this kind of memory
management actually is on SMP vs. UP systems, but the intended
functionality of local_flush_tlb_kernel_range seems like it should
exist even on UP, to me.

--
Matt Sealey <matt@...esi-usa.com>
Product Development Analyst, Genesi USA, Inc.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists