[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <B01EB0A1-992B-49F4-93AE-71E4BA707795@arm.com>
Date: Wed, 11 Jun 2014 23:00:18 +0100
From: Catalin Marinas <catalin.marinas@....com>
To: Denis Kirjanov <kda@...ux-powerpc.org>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-mm@...ck.org" <linux-mm@...ck.org>
Subject: Re: kmemleak: Unable to handle kernel paging request
On 11 Jun 2014, at 21:04, Denis Kirjanov <kda@...ux-powerpc.org> wrote:
> On 6/11/14, Catalin Marinas <catalin.marinas@....com> wrote:
>> On Wed, Jun 11, 2014 at 04:13:07PM +0400, Denis Kirjanov wrote:
>>> I got a trace while running 3.15.0-08556-gdfb9454:
>>>
>>> [ 104.534026] Unable to handle kernel paging request for data at
>>> address 0xc00000007f000000
>>
>> Were there any kmemleak messages prior to this, like "kmemleak
>> disabled"? There could be a race when kmemleak is disabled because of
>> some fatal (for kmemleak) error while the scanning is taking place
>> (which needs some more thinking to fix properly).
>
> No. I checked for the similar problem and didn't find anything relevant.
> I'll try to bisect it.
Does this happen soon after boot? I guess it’s the first scan
(scheduled at around 1min after boot). Something seems to be telling
kmemleak that there is a valid memory block at 0xc00000007f000000.
Catalin--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists