Comment 3 for bug 1012085

Analysis update:

It seems, the virtual address range issued by the alloc_vmap_area for the 128 pages, seems to be already mapped by iotable.

/proc/vmallocinfo revealed.

0xf8007000-0xf8008000 4096 iotable_init+0x0/0xbc phys=80007000 ioremap
0xf800e000-0xf800f000 4096 iotable_init+0x0/0xbc phys=8000e000 ioremap
0xf800f000-0xf8010000 4096 iotable_init+0x0/0xbc phys=8000f000 ioremap

and /proc/iomem revealed,

80007000-80007fff : uart2
  80007000-80007fff : uart-pl011
8000e000-8000e07f : gpio.2
  8000e000-8000e07f : gpio.2
8000e080-8000e0ff : gpio.3
  8000e080-8000e0ff : gpio.3
8000e100-8000e17f : gpio.4
  8000e100-8000e17f : gpio.4
8000e180-8000e1ff : gpio.5
  8000e180-8000e1ff : gpio.5
80118000-80118fff : sdi1
  80118000-80118fff : mmci-pl18x
80128000-80128fff : nmk-i2c.2
  80128000-80128fff : nmk-i2cI/O region

So, here the virtual address "4160778240 (0xf8007000)" whose pte entry is failing, in vmalloc_user function, seems
to be already, mapped by iotable_init for uart2, gpio.2 peripherals.
So, the vmalloc algorithm, gives a virtual address range which seems to be already mapped by iotable_init. This seems to be bit odd.

Analysis in progress.
Comments are welcome