From: "Kirill A. Shutemov" <kirill@shutemov.name>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Dmitry Vyukov <dvyukov@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>,
Hugh Dickins <hughd@google.com>, Greg Thelen <gthelen@google.com>,
Konstantin Khlebnikov <koct9i@gmail.com>,
syzkaller <syzkaller@googlegroups.com>,
Kostya Serebryany <kcc@google.com>,
Alexander Potapenko <glider@google.com>,
Sasha Levin <sasha.levin@oracle.com>,
Andrea Arcangeli <aarcange@redhat.com>
Subject: Re: mm: BUG in khugepaged_scan_mm_slot
Date: Mon, 4 Apr 2016 15:06:25 +0300 [thread overview]
Message-ID: <20160404120625.GA6133@node.shutemov.name> (raw)
In-Reply-To: <5702582A.1030904@suse.cz>
On Mon, Apr 04, 2016 at 02:03:54PM +0200, Vlastimil Babka wrote:
> [+CC Andrea]
>
> On 04/02/2016 11:48 AM, Dmitry Vyukov wrote:
> >Hello,
> >
> >The following program triggers a BUG in khugepaged_scan_mm_slot:
> >
> >
> >vma ffff880032698f90 start 0000000020c57000 end 0000000020c58000
> >next ffff88003269a1b8 prev ffff88003269ac18 mm ffff88005e274780
> >prot 35 anon_vma ffff88003182c000 vm_ops (null)
> >pgoff fed00 file ffff8800324552c0 private_data (null)
> >flags: 0x5144477(read|write|exec|mayread|maywrite|mayexec|pfnmap|io|dontexpand|account)
> >------------[ cut here ]------------
> >kernel BUG at mm/huge_memory.c:2313!
> >invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN
>
> That's VM_BUG_ON_VMA(vma->vm_flags & VM_NO_THP, vma) in
> hugepage_vma_check().
>
> #define VM_NO_THP (VM_SPECIAL | VM_HUGETLB | VM_SHARED | VM_MAYSHARE)
>
> #define VM_SPECIAL (VM_IO | VM_DONTEXPAND | VM_PFNMAP | VM_MIXEDMAP)
>
> Of those, we have VM_IO | VM_DONTEXPAND.
>
> I don't know if it's valid for a vma with anon_vma to have such flags, if
> yes, we should probably modify hugepage_vma_check(). Called from
> khugepaged_scan_mm_slot() it should just return false out VM_NO_THP. Called
> from collapse_huge_page() it could keep the VM_BUG_ON. Or maybe just have
> VM_BUG_ON(!hugepage_vma_check()) there? Hmm actually no, there's a mmap_sem
> release for read and then acquire for write, so we can't rely on the check
> done earlier from khugepaged_scan_mm_slot().
>
> So we should probably just change the VM_BUG_ON to another "return false"
> condition. Unless the VM_BUG_ON uncovered a real bug and the earlier
> conditions in hugepage_vma_check() should guarantee the VM_BUG_ON be false
> for any vma.
http://lkml.kernel.org/r/145961146490.28194.16019687861681349309.stgit@zurg
--
Kirill A. Shutemov
--
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>
WARNING: multiple messages have this Message-ID (diff)
From: "Kirill A. Shutemov" <kirill@shutemov.name>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Dmitry Vyukov <dvyukov@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>,
Hugh Dickins <hughd@google.com>, Greg Thelen <gthelen@google.com>,
Konstantin Khlebnikov <koct9i@gmail.com>,
syzkaller <syzkaller@googlegroups.com>,
Kostya Serebryany <kcc@google.com>,
Alexander Potapenko <glider@google.com>,
Sasha Levin <sasha.levin@oracle.com>,
Andrea Arcangeli <aarcange@redhat.com>
Subject: Re: mm: BUG in khugepaged_scan_mm_slot
Date: Mon, 4 Apr 2016 15:06:25 +0300 [thread overview]
Message-ID: <20160404120625.GA6133@node.shutemov.name> (raw)
In-Reply-To: <5702582A.1030904@suse.cz>
On Mon, Apr 04, 2016 at 02:03:54PM +0200, Vlastimil Babka wrote:
> [+CC Andrea]
>
> On 04/02/2016 11:48 AM, Dmitry Vyukov wrote:
> >Hello,
> >
> >The following program triggers a BUG in khugepaged_scan_mm_slot:
> >
> >
> >vma ffff880032698f90 start 0000000020c57000 end 0000000020c58000
> >next ffff88003269a1b8 prev ffff88003269ac18 mm ffff88005e274780
> >prot 35 anon_vma ffff88003182c000 vm_ops (null)
> >pgoff fed00 file ffff8800324552c0 private_data (null)
> >flags: 0x5144477(read|write|exec|mayread|maywrite|mayexec|pfnmap|io|dontexpand|account)
> >------------[ cut here ]------------
> >kernel BUG at mm/huge_memory.c:2313!
> >invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN
>
> That's VM_BUG_ON_VMA(vma->vm_flags & VM_NO_THP, vma) in
> hugepage_vma_check().
>
> #define VM_NO_THP (VM_SPECIAL | VM_HUGETLB | VM_SHARED | VM_MAYSHARE)
>
> #define VM_SPECIAL (VM_IO | VM_DONTEXPAND | VM_PFNMAP | VM_MIXEDMAP)
>
> Of those, we have VM_IO | VM_DONTEXPAND.
>
> I don't know if it's valid for a vma with anon_vma to have such flags, if
> yes, we should probably modify hugepage_vma_check(). Called from
> khugepaged_scan_mm_slot() it should just return false out VM_NO_THP. Called
> from collapse_huge_page() it could keep the VM_BUG_ON. Or maybe just have
> VM_BUG_ON(!hugepage_vma_check()) there? Hmm actually no, there's a mmap_sem
> release for read and then acquire for write, so we can't rely on the check
> done earlier from khugepaged_scan_mm_slot().
>
> So we should probably just change the VM_BUG_ON to another "return false"
> condition. Unless the VM_BUG_ON uncovered a real bug and the earlier
> conditions in hugepage_vma_check() should guarantee the VM_BUG_ON be false
> for any vma.
http://lkml.kernel.org/r/145961146490.28194.16019687861681349309.stgit@zurg
--
Kirill A. Shutemov
next prev parent reply other threads:[~2016-04-04 12:06 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-02 9:48 mm: BUG in khugepaged_scan_mm_slot Dmitry Vyukov
2016-04-02 9:48 ` Dmitry Vyukov
2016-04-04 12:03 ` Vlastimil Babka
2016-04-04 12:03 ` Vlastimil Babka
2016-04-04 12:06 ` Kirill A. Shutemov [this message]
2016-04-04 12:06 ` Kirill A. Shutemov
2016-04-04 17:15 ` Andrea Arcangeli
2016-04-04 17:15 ` Andrea Arcangeli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160404120625.GA6133@node.shutemov.name \
--to=kirill@shutemov.name \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=dvyukov@google.com \
--cc=glider@google.com \
--cc=gthelen@google.com \
--cc=hughd@google.com \
--cc=kcc@google.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=koct9i@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=sasha.levin@oracle.com \
--cc=syzkaller@googlegroups.com \
--cc=vbabka@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.