From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755176AbdGCQyT (ORCPT ); Mon, 3 Jul 2017 12:54:19 -0400 Received: from mx2.suse.de ([195.135.220.15]:43462 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754343AbdGCQyQ (ORCPT ); Mon, 3 Jul 2017 12:54:16 -0400 Date: Mon, 3 Jul 2017 18:54:12 +0200 From: Michal Hocko To: Linus Torvalds Cc: Oleg Nesterov , Hugh Dickins , Andrew Morton , Larry Woodman , Linux Kernel Mailing List Subject: Re: [PATCH 0/1] expand_downwards: don't require the gap if !vm_prev Message-ID: <20170703165412.GG11848@dhcp22.suse.cz> References: <20170628175237.GA24868@redhat.com> <20170630132439.GL22917@dhcp22.suse.cz> <20170630172602.GD9714@dhcp22.suse.cz> <20170703154925.GD11848@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Mon 03-07-17 09:30:35, Linus Torvalds wrote: > On Mon, Jul 3, 2017 at 8:49 AM, Michal Hocko wrote: > > > > If you think this is worth pursuing in upstream, just let me know and I > > can polish it, add a patch for the man page and other things. > > Hmm. This doesn't look bad, except the bprm games there really look annoying. > > Also, I'm wondering whether this should be per-thread - conceptually > "expand_stack()" really is a thread thing. All callers are using > "current", although it's not always obvious. > > So I'm wondering if a slightly larger patch that simply made the > "limit" be an _argument_ to expand_stack() would clean up both of > these issues. The execve() use would simply pass in the stack limit, > and the fault users would pass in "current->expand_stack_limit". > > Again, I'm not sure how many people really use multiple GROW_DOWN > stacks for threading, but it's conceptually the right thing to do, so > I think conceptually this should be per-thread. And the fact that it > might clean up the execve() thing makes me think it's the right thing > to do. > > What do you think? I am not sure about the per-thread vs. per mm part. If for nothing else, MAP_GROWSDOWN can be something else than the main thread stack which can be modified by all threads and then the semantic would be quite surprising if different threads had a different idea about the expansion. No? But an additional argument to expand_stack would surely clean things up a bit and will get rid of the ugly bprm part as well. I will think about it some more and then post the patch to linux-api to have a larger audience. Thanks! -- Michal Hocko SUSE Labs