Messages in this thread | | | Date | Fri, 21 Feb 2014 12:18:11 -0500 | From | Sasha Levin <> | Subject | Re: [PATCH 11/11] mempolicy: apply page table walker on queue_pages_range() |
| |
On 02/21/2014 11:58 AM, Naoya Horiguchi wrote: > Hi Sasha, > > On Fri, Feb 21, 2014 at 01:30:53AM -0500, Sasha Levin wrote: >> On 02/10/2014 04:44 PM, Naoya Horiguchi wrote: >>> queue_pages_range() does page table walking in its own way now, >>> so this patch rewrites it with walk_page_range(). >>> One difficulty was that queue_pages_range() needed to check vmas >>> to determine whether we queue pages from a given vma or skip it. >>> Now we have test_walk() callback in mm_walk for that purpose, >>> so we can do the replacement cleanly. queue_pages_test_walk() >>> depends on not only the current vma but also the previous one, >>> so we use queue_pages->prev to keep it. >>> >>> ChangeLog v2: >>> - rebase onto mmots >>> - add VM_PFNMAP check on queue_pages_test_walk() >>> >>> Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> >>> --- >> >> Hi Naoya, >> >> I'm seeing another spew in today's -next, and it seems to be related >> to this patch. Here's the spew (with line numbers instead of kernel >> addresses): > > Thanks. (line numbers translation is very helpful.) > > This bug looks strange to me. > "kernel BUG at mm/hugetlb.c:3580" means we try to do isolate_huge_page() > for !PageHead page. But the caller queue_pages_hugetlb() gets the page > with "page = pte_page(huge_ptep_get(pte))", so it should be the head page! > > mm/hugetlb.c:3580 is VM_BUG_ON_PAGE(!PageHead(page), page), so we expect to > have dump_page output at this point, is that in your kernel log?
This is usually a sign of a race between that code and thp splitting, see https://lkml.org/lkml/2013/12/23/457 for example.
I forgot to add the dump_page output to my extraction process and the complete logs all long gone. I'll grab it when it happens again.
Thanks, Sasha
| |