Re: kmemleak: Unable to handle kernel paging request

[Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>]

Hi Denis,

On Thu, Jun 12, 2014 at 04:00:57PM +0400, Denis Kirjanov wrote:
> 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

Thanks for the effort of bisecting.
I guess that this bug happens because pte_none() check was gone in this
commit, so could you try to find if the following patch fixes the problem?

I don't know much about kmemleak's details, so I'm not sure how this bug
affected kmemleak. So I'm appreciated if you would add some comment in
patch description.

Thanks,
Naoya Horiguchi
---
Date: Thu, 12 Jun 2014 08:56:27 -0400
Subject: [PATCH] mm: revoke pte_none() check for hugetlb_entry() callbacks

commit: d4c54919ed86302094c0ca7d48a8cbd4ee753e92 ("mm: add !pte_present()
check on existing hugetlb_entry callbacks") removed pte_none() check in
a ->hugetlb_entry() handler, which unexpectedly broke other features like
kmemleak.

pte_none() check should be done in common page walk code, because we do
so for normal pages and page walk might want to handle holes with
->pte_hole() callback.

Reported-by: Denis Kirjanov <kda@linux-powerpc.org>
Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
---
 mm/pagewalk.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/mm/pagewalk.c b/mm/pagewalk.c
index 2beeabf502c5..0618657285c4 100644
--- a/mm/pagewalk.c
+++ b/mm/pagewalk.c
@@ -118,6 +118,13 @@ static int walk_hugetlb_range(struct vm_area_struct *vma,
 	do {
 		next = hugetlb_entry_end(h, addr, end);
 		pte = huge_pte_offset(walk->mm, addr & hmask);
+		if (huge_pte_none(*pte)) {
+			if (walk->pte_hole)
+				err = walk->pte_hole(addr, next, walk);
+			if (err)
+				break;
+			continue;
+		}
 		if (pte && walk->hugetlb_entry)
 			err = walk->hugetlb_entry(pte, hmask, addr, next, walk);
 		if (err)
-- 
1.9.3

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>