From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752294AbdF1Rwr (ORCPT ); Wed, 28 Jun 2017 13:52:47 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35200 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751647AbdF1Rwl (ORCPT ); Wed, 28 Jun 2017 13:52:41 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 2C5DA3DBDE Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=oleg@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 2C5DA3DBDE Date: Wed, 28 Jun 2017 19:52:37 +0200 From: Oleg Nesterov To: Hugh Dickins Cc: Andrew Morton , Larry Woodman , Linus Torvalds , Michal Hocko , linux-kernel@vger.kernel.org Subject: [PATCH 0/1] expand_downwards: don't require the gap if !vm_prev Message-ID: <20170628175237.GA24868@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Wed, 28 Jun 2017 17:52:41 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org See the patch, but actually I have another question... Now that the stack-guard-page has gone, why do we need to allow to grow into the previous VM_GROWSDOWN vma? IOW, why we can not simply remove the VM_GROWSDOWN check in expand_downwards() ? Yes, this is what the kernel did before the recent changes. But afaics only because the kernel could not know if the vma->vm_start page is actually guard or not. IOW, iiuc before the recent change it was not simple to _disallow_ this, and that is why it worked. Just for example, suppose an application does addr = mmap(MAP_GROWSDOWN); mprotect(addr, PAGE_SIZE, PROT_NONE); *(addr + PAGE_SIZE) = 0; and of course this should not fail. But the the kernel could not know if vm_start == addr + PAGE_SIZE is the "valid" address, or this vma was expanded before and vm_start is the stack guard. Yes, we can probably check anon_vma's as the comment suggests, but imo we we can just remove the VM_GROWSDOWN case unconditionally. Oleg.