lkml.org 
[lkml]   [2021]   [Apr]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [LKP] Re: [mm/vunmap] e47110e905: WARNING:at_mm/vmalloc.c:#__vunmap
From
Date
Hi Linus,

On 4/24/2021 1:18 AM, Linus Torvalds wrote:
> On Thu, Apr 22, 2021 at 11:15 PM kernel test robot
> <oliver.sang@intel.com> wrote:
>>
>> commit: e47110e90584a22e9980510b00d0dfad3a83354e ("mm/vunmap: add cond_resched() in vunmap_pmd_range")
>
> Funky. That commit doesn't seem to have anything to do with the oops.
>
> The oops is odd too:
>
>> [ 198.731223] WARNING: CPU: 0 PID: 1948 at mm/vmalloc.c:2247 __vunmap (kbuild/src/consumer/mm/vmalloc.c:2247 (discriminator 1))
>
> That's the warning for an unaligned vunmap():
>
> 2247 if (WARN(!PAGE_ALIGNED(addr), "Trying to vfree() bad
> address (%p)\n",
> 2248 addr))
> 2249 return;
>
>> [ 198.744933] Call Trace:
>> [ 198.745229] free_module (kbuild/src/consumer/kernel/module.c:2251)
>
> 2248 /* This may be empty, but that's OK */
> 2249 module_arch_freeing_init(mod);
> 2250 module_memfree(mod->init_layout.base);

We add debug code to print logs when mod->init_layout.base is NULL,
after more than 100 times test, we find that when mod->init_layout.base
is NULL, no align warning happened. From the descriptions of vfree, if
@addr is NULL, no operation is performed. So when the warning happened,
the mod->init_layout.base is not a NULL.

void vfree(const void *addr)
{
BUG_ON(in_nmi());

kmemleak_free(addr);

might_sleep_if(!in_interrupt());

if (!addr)
return;

__vfree(addr);
}

static void __vfree(const void *addr)
{
if (unlikely(in_interrupt()))
__vfree_deferred(addr);
else
__vunmap(addr, 1);
}


> 2251 kfree(mod->args);
>
> That's the "module_memfree()" - the return address points to the
> return point, which is the next line.
>
> And as far as I can tell, the only thing that assigns anything but
> NULL to that init_layout.base is
>
> ptr = module_alloc(mod->init_layout.size);
>
> which uses __vmalloc_node_range() for the allocation.
>
> So absolutely nothing in this report makes sense to me. I suspect it's
> some odd memory corruption.
>
> Oliver - how reliable is that bisection?
>
> Does anybody else see what might be up?
>
> Linus
> _______________________________________________
> LKP mailing list -- lkp@lists.01.org
> To unsubscribe send an email to lkp-leave@lists.01.org
>

--
Zhengjun Xing

\
 
 \ /
  Last update: 2021-04-28 10:33    [W:0.578 / U:0.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site