lkml.org 
[lkml]   [2014]   [Jun]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: kmemleak: Unable to handle kernel paging request
From
On 6/12/14, Denis Kirjanov <kda@linux-powerpc.org> wrote:
> On 6/12/14, Catalin Marinas <catalin.marinas@arm.com> wrote:
>> On 11 Jun 2014, at 21:04, Denis Kirjanov <kda@linux-powerpc.org> wrote:
>>> On 6/11/14, Catalin Marinas <catalin.marinas@arm.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.
>
> Yeah, it happens after a while with a booted system so that's the
> first kmemleak scan.
>
>> Catalin
>

I've bisected to this commit: d4c54919ed86302094c0ca7d48a8cbd4ee753e92
"mm: add !pte_present() check on existing hugetlb_entry callbacks".
Reverting the commit fixes the issue
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2014-06-12 14:21    [W:0.082 / U:1.124 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site