On Tue, May 27, 2014 at 2:31 PM, Kirill A. Shutemov
<kirill.shutemov@xxxxxxxxxxxxxxx> wrote:
> Vinayak Menon wrote:
>> An issue was observed when a userspace task exits.
>> The page which hits error here is the zero page.
>> In zap_pte_range, vm_normal_page gets called, and it
>> returns a page address and not NULL, even though the
>> pte corresponds to zero pfn. In this case,
>> HAVE_PTE_SPECIAL is not set, and VM_MIXEDMAP is set
>> in vm_flags. In the case of VM_MIXEDMAP , only pfn_valid
>> is checked, and not is_zero_pfn. This results in
>> zero page being returned instead of NULL.
>>
>> BUG: Bad page map in process mediaserver pte:9dff379f pmd:9bfbd831
>> page:c0ed8e60 count:1 mapcount:-1 mapping: (null) index:0x0
>> page flags: 0x404(referenced|reserved)
>> addr:40c3f000 vm_flags:10220051 anon_vma: (null) mapping:d9fe0764 index:fd
>> vma->vm_ops->fault: (null)
>> vma->vm_file->f_op->mmap: binder_mmap+0x0/0x274
>
> How do we get zero_pfn there. We shouldn't use zero page for file mappings.
> binder does some tricks?
Its vm_ops doesn't provide ->fault method at all.
Seems like all ptes must be populated at the mmap time.
For some reason read page fault had happened and handle_pte_fault()
handled it in do_anonymous_page() which maps zero_page.
>
>> CPU: 0 PID: 1463 Comm: mediaserver Tainted: G W 3.10.17+ #1
>> [<c001549c>] (unwind_backtrace+0x0/0x11c) from [<c001200c>] (show_stack+0x10/0x14)
>> [<c001200c>] (show_stack+0x10/0x14) from [<c0103d78>] (print_bad_pte+0x158/0x190)
>> [<c0103d78>] (print_bad_pte+0x158/0x190) from [<c01055f0>] (unmap_single_vma+0x2e4/0x598)
>> [<c01055f0>] (unmap_single_vma+0x2e4/0x598) from [<c010618c>] (unmap_vmas+0x34/0x50)
>> [<c010618c>] (unmap_vmas+0x34/0x50) from [<c010a9e4>] (exit_mmap+0xc8/0x1e8)
>> [<c010a9e4>] (exit_mmap+0xc8/0x1e8) from [<c00520f0>] (mmput+0x54/0xd0)
>> [<c00520f0>] (mmput+0x54/0xd0) from [<c005972c>] (do_exit+0x360/0x990)
>> [<c005972c>] (do_exit+0x360/0x990) from [<c0059ef0>] (do_group_exit+0x84/0xc0)
>> [<c0059ef0>] (do_group_exit+0x84/0xc0) from [<c0066de0>] (get_signal_to_deliver+0x4d4/0x548)
>> [<c0066de0>] (get_signal_to_deliver+0x4d4/0x548) from [<c0011500>] (do_signal+0xa8/0x3b8)
>>
>> Signed-off-by: Vinayak Menon <vinayakm.list@xxxxxxxxx>
>> ---
>> mm/memory.c | 2 ++
>> 1 files changed, 2 insertions(+), 0 deletions(-)
>>
>> diff --git a/mm/memory.c b/mm/memory.c
>> index 037b812..c9a5027 100644
>> --- a/mm/memory.c
>> +++ b/mm/memory.c
>> @@ -771,6 +771,8 @@ struct page *vm_normal_page(struct vm_area_struct *vma, unsigned long addr,
>> if (vma->vm_flags & VM_MIXEDMAP) {
>> if (!pfn_valid(pfn))
>> return NULL;
>> + if (is_zero_pfn(pfn))
>> + return NULL;
>> goto out;
>> } else {
>> unsigned long off;
>> --
>> 1.7.6
>>
>
> --
> Kirill A. Shutemov
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@xxxxxxxxx. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>