lkml.org 
[lkml]   [2019]   [Jan]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: kmemleak panic
On Fri, Jan 18, 2019 at 04:36:59PM +0100, Marc Gonzalez wrote:
> mount -t debugfs nodev /sys/kernel/debug/
> echo scan > /sys/kernel/debug/kmemleak
>
> Unable to handle kernel paging request at virtual address ffffffc021e00000
[...]
> Call trace:
> scan_block+0x70/0x190
> scan_gray_list+0x108/0x1c0
> kmemleak_scan+0x33c/0x7c0
> kmemleak_write+0x410/0x4b0

As per Robin's remark, this address seems to be pretty easy to
reproduce. It also happens via scan_gray_list() which indicates an
object kmemleak was informed about via kmemleak_alloc() (so this
excludes the pfn that Qian noticed).

Can you configure the kernel with CONFIG_DEBUG_KMEMLEAK_AUTO_SCAN off
just to avoid the bug being triggered early and run:

mount -t debugfs nodev /sys/kernel/debug/
echo dump=0xffffffc021e00000 > /sys/kernel/debug/kmemleak

Then run another scan to make sure this is the address that triggered
the page fault:

echo scan > /sys/kernel/debug/kmemleak

The above should tell us where the object that kmemleak is trying to
scan came from.

Of course, ideally we should bisect this but I haven't been able to
reproduce it.

--
Catalin

\
 
 \ /
  Last update: 2019-01-19 14:29    [W:0.120 / U:0.084 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site