linux-kernel - Re: [PATCH 11/11] mempolicy: apply page table walker on queue_pages

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <5309F1F8.6040006@oracle.com>
Date:	Sun, 23 Feb 2014 08:04:56 -0500
From:	Sasha Levin <sasha.levin@...cle.com>
To:	Naoya Horiguchi <n-horiguchi@...jp.nec.com>
CC:	linux-mm@...ck.org, akpm@...ux-foundation.org, mpm@...enic.com,
	cpw@....com, kosaki.motohiro@...fujitsu.com, hannes@...xchg.org,
	kamezawa.hiroyu@...fujitsu.com, mhocko@...e.cz,
	aneesh.kumar@...ux.vnet.ibm.com, xemul@...allels.com,
	riel@...hat.com, kirill.shutemov@...ux.intel.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 11/11] mempolicy: apply page table walker on queue_pages_range()

On 02/21/2014 12:25 PM, Naoya Horiguchi wrote:
> On Fri, Feb 21, 2014 at 12:18:11PM -0500, Sasha Levin wrote:
>> On 02/21/2014 11:58 AM, Naoya Horiguchi wrote:
>>> 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@...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.
> 
> queue_pages_hugetlb() is for hugetlbfs, not for thp, so I don't think that
> it's related to thp splitting, but I agree it's a race.
> 
>> 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.
> 
> Thank you. It'll be useful.

And here it is:

[  755.524966] page:ffffea0000000000 count:0 mapcount:1 mapping:          (null) index:0x0
[  755.526067] page flags: 0x0()

Followed by the same stack trace as before.


Thanks,
Sasha

--
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/