Maybe try to increase the module-section size to see if it solves the
problem.
What would be the easiest way to do that?
Sorry for late answer. I was trying to reproduce it on my box. What i
did was trying to load all modules in my system with KASAN_INLINE option:
Thanks!
<snip>
#!/bin/bash
# Exclude test_vmalloc.ko
MODULES_LIST=(`find /lib/modules/$(uname -r) -type f \
\( -iname "*.ko" -not -iname "test_vmalloc*" \) | awk -F"/" '{print $NF}' | sed 's/.ko//'`)
function moduleExist(){
MODULE="$1"
if lsmod | grep "$MODULE" &> /dev/null ; then
return 0
else
return 1
fi
}
i=0
for module_name in ${MODULES_LIST[@]}; do
sudo modprobe $module_name
if moduleExist ${module_name}; then
((i=i+1))
echo "Successfully loaded $module_name counter $i"
fi
done
<snip>
as you wrote it looks like it is not easy to reproduce. So i do not see
any vmap related errors.
Yeah, it's quite mystery and only seems to trigger on these systems with
a lot of CPUs.
Returning back to the question. I think you could increase the MODULES_END
address and shift the FIXADDR_START little forward. See the dump_pagetables.c
But it might be they are pretty compact and located in the end. So i am not
sure if there is a room there.
That's what I was afraid of :)
Second. It would be good to understand if vmap only fails on allocating for a
module:
<snip>
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index dd6cdb201195..53026fdda224 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -1614,6 +1614,8 @@ static struct vmap_area *alloc_vmap_area(unsigned long size,
va->va_end = addr + size;
va->vm = NULL;
+ trace_printk("-> alloc %lu size, align: %lu, vstart: %lu, vend: %lu\n", size, align, vstart, vend);
+
spin_lock(&vmap_area_lock);
<snip>
I'll try grabbing a suitable system again and add some more debugging
output. Might take a while, unfortunately.
--
Thanks,
David / dhildenb
