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 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 0xf800f000 4096 iotable_ init+0x0/ 0xbc phys=8000e000 ioremap 0xf8010000 4096 iotable_ init+0x0/ 0xbc phys=8000f000 ioremap
0xf800e000-
0xf800f000-
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