Bug 104691

Summary: [bisected] regression, crash at start of oracle instance
Product: Memory Management Reporter: William Shuman (wshuman3)
Component: OtherAssignee: Andrew Morton (akpm)
Status: RESOLVED CODE_FIX    
Severity: normal CC: wshuman3
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 4.3rc-1 Subsystem:
Regression: No Bisected commit-id:
Attachments: gdb bt
oracle trace

Description William Shuman 2015-09-16 19:47:16 UTC
Created attachment 187761 [details]
gdb bt

This commit is causing oracle db to crash on start.  Attached is core dump bt and some of the trace from oracle.  Let me know if I can provide anymore information.

6dc296e7df4c9a0857491cc3f55da16a9eeeeae7 is the first bad commit
commit 6dc296e7df4c9a0857491cc3f55da16a9eeeeae7
Author: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Date:   Wed Sep 9 15:39:32 2015 -0700

    mm: make sure all file VMAs have ->vm_ops set
    
    We rely on vma->vm_ops == NULL to detect anonymous VMA: see
    vma_is_anonymous(), but some drivers doesn't set ->vm_ops.
    
    As a result we can end up with anonymous page in private file mapping.
    That should not lead to serious misbehaviour, but nevertheless is wrong.
    
    Let's fix by setting up dummy ->vm_ops for file mmapping if f_op->mmap()
    didn't set its own.
    
    The patch also adds sanity check into __vma_link_rb(). It will help
    catch broken VMAs which inserted directly into mm_struct via
    insert_vm_struct().
    
    Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Reviewed-by: Oleg Nesterov <oleg@redhat.com>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: Andy Lutomirski <luto@amacapital.net>
    Cc: Dave Hansen <dave.hansen@linux.intel.com>
    Cc: Ingo Molnar <mingo@elte.hu>
    Cc: Minchan Kim <minchan@kernel.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

:040000 040000 20ce7f3affa69ebd064a68043241043052770f61 0a36c905c5a14c48ba43bc917d7485ba051a68db M	mm
Comment 1 William Shuman 2015-09-16 19:47:41 UTC
Created attachment 187771 [details]
oracle trace