Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751036AbdFTCcD (ORCPT ); Mon, 19 Jun 2017 22:32:03 -0400 Received: from mail-io0-f176.google.com ([209.85.223.176]:35120 "EHLO mail-io0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750863AbdFTCcB (ORCPT ); Mon, 19 Jun 2017 22:32:01 -0400 MIME-Version: 1.0 In-Reply-To: <20170620002612.bwjphlk2qz3ynghl@codemonkey.org.uk> References: <20170620002612.bwjphlk2qz3ynghl@codemonkey.org.uk> From: Linus Torvalds Date: Tue, 20 Jun 2017 10:32:00 +0800 X-Google-Sender-Auth: 9jW3486-Yi0zS6YRBpSWAuqNCHU Message-ID: Subject: Re: Linux 4.12-rc6 To: Dave Jones , Linus Torvalds , Linux Kernel Mailing List , Hugh Dickins , Oleg Nesterov , Michal Hocko Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2526 Lines: 67 On Tue, Jun 20, 2017 at 8:26 AM, Dave Jones wrote: > > Hugh Dickins (1): > > mm: larger stack guard gap, between vmas > > This seems to be buggered. > > 002331 00000396712307 0 2 kernel BUG at mm/mmap.c:1963! > 002332 00000396712414 0 4 invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC > 002333 00000396712541 0 4 CPU: 0 PID: 4572 Comm: trinity-c41 Not tainted 4.12.0-rc6-think+ #1 > 002336 00000396712959 0 4 RIP: 0010:unmapped_area_topdown+0xa5/0x170 Dave, do you have instructions for Hugh to recreate that with trinity (or perhaps some way to generate a test-case from trinity?). Or does it trigger easily by just running trinity? I'm in China right now, and will be traveling again this afternoon, so I probably can't look at it myself until later, but hopefully Hugh has the cycles to follow up in it.. Hugh? The changes to unmapped_area_topdown() look trivial, but obviously there's something wrong there. The code decodes to 49 39 c0 cmp %rax,%r8 76 d0 jbe 0xfffffffffffffffb * 0f 0b ud2 <-- trapping instruction so from the VM_BUG_ON(gap_end < gap_start); we have gap_start/end in %r8 and %rax respectively, which are: R08: 00007f7d54673000 RAX: 00007f7d543d6000 so yes, gap_start is bigger than gap_end there by quite a degree (more than the 1MB of the gap size unless I looked at it wrong). Hmm. Maybe it's this: /* Check if current node has a suitable gap */ gap_end = vm_start_gap(vma); if (gap_end < low_limit) return -ENOMEM; if (gap_start <= high_limit && gap_end - gap_start >= length) goto found; where it used to be that gap_end was guaranteed to be after gap_start, but that's no longer true. We have gap_start = vma->vm_prev ? vm_end_gap(vma->vm_prev) : 0; gap_end = vm_start_gap(vma); and by using MAP_FIXED, you can end up in the situation that "vma->vm_prev" is closer to vma than the gap size. So now gap_end - gap_start will underflow, and then the logic that does "goto found" thinks it found a hole that is larger than "length", when in actual fact it found a "negative-size" hole. So maybe that "goto found" condition should have an additional test for "gap_end > gap_start"? Or maybe I'm just hallucinating and missed something. Hugh, Oleg, Michal, can you take another look and double-check this logic? Linus