From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752331AbdGETKM (ORCPT ); Wed, 5 Jul 2017 15:10:12 -0400 Received: from mx2.suse.de ([195.135.220.15]:60492 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752086AbdGETKL (ORCPT ); Wed, 5 Jul 2017 15:10:11 -0400 Date: Wed, 5 Jul 2017 21:10:07 +0200 From: Michal Hocko To: Linus Torvalds Cc: Andrew Morton , Vlastimil Babka , Ben Hutchings , Willy Tarreau , Oleg Nesterov , Rik van Riel , LKML , linux-mm Subject: Re: [PATCH] mm: mm, mmap: do not blow on PROT_NONE MAP_FIXED holes in the stack Message-ID: <20170705191007.GA26635@dhcp22.suse.cz> References: <20170705165602.15005-1-mhocko@kernel.org> <20170705182849.GA18027@dhcp22.suse.cz> <20170705185302.GA24733@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170705185302.GA24733@dhcp22.suse.cz> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed 05-07-17 20:53:02, Michal Hocko wrote: > On Wed 05-07-17 11:35:51, Linus Torvalds wrote: > > On Wed, Jul 5, 2017 at 11:28 AM, Michal Hocko wrote: > > > > > > Dohh, that was on mmotm which has a clean up by Oleg which reorganizes > > > the code a bit. This is on top of the current master > > > > Oh, ok. I think I know which patch from Oleg you're talking about. > > > > Since I do want that patch too, and since I'd hate to cause > > unnecessary merge conflicts in this area, how about we just plan on > > letting your original patch (on top of Oleg's) go through Andrew and > > the -mm tree? I'll get it that way, and it's not like this is > > timing-critical. > > That would lead to conflicts when backporting to stable trees though > which is quite annoying as well and arguably slightly more annoying than > resolving this in mmotm. I can help to rebase Oleg's patch on top of > mine which is not a stable material. Here is the rebase of Oleg's patch. --- >>From 61ff0cd972dac218390a5859b89ce386db731d1d Mon Sep 17 00:00:00 2001 From: Oleg Nesterov Date: Fri, 30 Jun 2017 10:19:00 +0200 Subject: [PATCH] mm/mmap.c: expand_downwards: don't require the gap if !vm_prev expand_stack(vma) fails if address < stack_guard_gap even if there is no vma->vm_prev. I don't think this makes sense, and we didn't do this before the recent commit 1be7107fbe18 ("mm: larger stack guard gap, between vmas"). We do not need a gap in this case, any address is fine as long as security_mmap_addr() doesn't object. This also simplifies the code, we know that address >= prev->vm_end and thus underflow is not possible. Link: http://lkml.kernel.org/r/20170628175258.GA24881@redhat.com Signed-off-by: Oleg Nesterov Cc: Hugh Dickins Cc: Larry Woodman Cc: Linus Torvalds Acked-by: Michal Hocko Signed-off-by: Michal Hocko --- mm/mmap.c | 10 +++------- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/mm/mmap.c b/mm/mmap.c index ece0f6d3a1b5..f30847405cab 100644 --- a/mm/mmap.c +++ b/mm/mmap.c @@ -2316,7 +2316,6 @@ int expand_downwards(struct vm_area_struct *vma, { struct mm_struct *mm = vma->vm_mm; struct vm_area_struct *prev; - unsigned long gap_addr; int error; address &= PAGE_MASK; @@ -2325,15 +2324,12 @@ int expand_downwards(struct vm_area_struct *vma, return error; /* Enforce stack_guard_gap */ - gap_addr = address - stack_guard_gap; - if (gap_addr > address) - return -ENOMEM; prev = vma->vm_prev; - if (prev && prev->vm_end > gap_addr && + /* Check that both stack segments have the same anon_vma? */ + if (prev && !(prev->vm_flags & VM_GROWSDOWN) && (prev->vm_flags & (VM_WRITE|VM_READ|VM_EXEC))) { - if (!(prev->vm_flags & VM_GROWSDOWN)) + if (address - prev->vm_end < stack_guard_gap) return -ENOMEM; - /* Check that both stack segments have the same anon_vma? */ } /* We must make sure the anon_vma is allocated. */ -- 2.11.0 -- Michal Hocko SUSE Labs