On Tue, Mar 17, 2015 at 09:27:36AM +0100, Ingo Molnar wrote:
> Ok, in any case I'm doing a rebase of the affected commits in
> tip:x86/asm. That's a tree where we don't want to break bisectability,
> and this breakage looks sufficiently mysterious.

Yeah.

And it keeps getting better and better. I added some debug output to the
PF-path to see why exactly we segfault and the guest booted fine! No
segfaults. So add timing to that failure :-(

---
diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index ede025fb46f1..54ca8539f345 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -746,6 +746,9 @@ show_signal_msg(struct pt_regs *regs, unsigned long 
error_code,
        print_vma_addr(KERN_CONT " in ", regs->ip);
 
        printk(KERN_CONT "\n");
+
+       dump_stack();
+
 }
 
 static void
@@ -827,8 +830,10 @@ __bad_area(struct pt_regs *regs, unsigned long error_code,
 }
 
 static noinline void
-bad_area(struct pt_regs *regs, unsigned long error_code, unsigned long address)
+bad_area(const char *where, struct pt_regs *regs, unsigned long error_code,
+        unsigned long address)
 {
+       pr_emerg("%s: %s\n", __func__, where);
        __bad_area(regs, error_code, address, SEGV_MAPERR);
 }
 
@@ -1189,13 +1194,13 @@ retry:
 
        vma = find_vma(mm, address);
        if (unlikely(!vma)) {
-               bad_area(regs, error_code, address);
+               bad_area("!vma", regs, error_code, address);
                return;
        }
        if (likely(vma->vm_start <= address))
                goto good_area;
        if (unlikely(!(vma->vm_flags & VM_GROWSDOWN))) {
-               bad_area(regs, error_code, address);
+               bad_area("!VM_GROWSDOWN", regs, error_code, address);
                return;
        }
        if (error_code & PF_USER) {
@@ -1206,12 +1211,12 @@ retry:
                 * 32 pointers and then decrements %sp by 65535.)
                 */
                if (unlikely(address + 65536 + 32 * sizeof(unsigned long) < 
regs->sp)) {
-                       bad_area(regs, error_code, address);
+                       bad_area("65536", regs, error_code, address);
                        return;
                }
        }
        if (unlikely(expand_stack(vma, address))) {
-               bad_area(regs, error_code, address);
+               bad_area("expand_stack", regs, error_code, address);
                return;
        }
 
diff --git a/mm/mmap.c b/mm/mmap.c
index da9990acc08b..47c4321f0d18 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -2225,13 +2225,17 @@ int expand_downwards(struct vm_area_struct *vma,
         * We must make sure the anon_vma is allocated
         * so that the anon_vma locking is not a noop.
         */
-       if (unlikely(anon_vma_prepare(vma)))
+       if (unlikely(anon_vma_prepare(vma))) {
+               pr_err("anon_vma_prepare\n");
                return -ENOMEM;
+       }
 
        address &= PAGE_MASK;
        error = security_mmap_addr(address);
-       if (error)
+       if (error) {
+               pr_err("security_mmap_addr\n");
                return error;
+       }
 
        vma_lock_anon_vma(vma);
 
@@ -2278,6 +2282,7 @@ int expand_downwards(struct vm_area_struct *vma,
        vma_unlock_anon_vma(vma);
        khugepaged_enter_vma_merge(vma, vma->vm_flags);
        validate_mm(vma->vm_mm);
+       pr_err("validate_mm: %d\n", error);
        return error;
 }
 
@@ -2326,11 +2331,15 @@ int expand_stack(struct vm_area_struct *vma, unsigned 
long address)
 {
        struct vm_area_struct *prev;
 
+       pr_err("%s: address: 0x%lx\n", __func__, address);
+
        address &= PAGE_MASK;
        prev = vma->vm_prev;
        if (prev && prev->vm_end == address) {
-               if (!(prev->vm_flags & VM_GROWSDOWN))
+               if (!(prev->vm_flags & VM_GROWSDOWN)) {
+                       pr_err("!(prev->vm_flags & VM_GROWSDOWN)\n");
                        return -ENOMEM;
+               }
        }
        return expand_downwards(vma, address);
 }

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to