On Mon, Oct 10, 2022 at 08:56:55AM +0200, David Hildenbrand wrote:
> > > > 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.
>
Yes that makes sense. Especially to understand if it fails on the MODULES_VADDR
- MODULES_END range or somewhere else. According to your trace output it looks
like that but it would be good to confirm it by adding some traces.
BTW, vmap code is lack of good trace events. Probably it is worth to add
some basic ones.
--
Uladzislau Rezki
