Received: by 10.223.185.116 with SMTP id b49csp5861768wrg; Tue, 27 Feb 2018 23:18:56 -0800 (PST) X-Google-Smtp-Source: AG47ELuTaE+XSTb9HLFO0nIdIQ03RN5soEQ6HSeMzuD47WmDjjY88bjFy+1BXtQDk7kZAAcsysYj X-Received: by 2002:a17:902:b690:: with SMTP id c16-v6mr8828085pls.264.1519802336704; Tue, 27 Feb 2018 23:18:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519802336; cv=none; d=google.com; s=arc-20160816; b=brL5aa19q1DEnZUh5BZuBGFv/k6TRVvtnwXYmZkrpo7T7VbQRw2nNR9eOIdG+cS+6O vSt9E4Ini+P2ZapApdPPq7o4qd0zvjKxTbLCG7RNHhnekPXBNFMELXn5fIOZreQ0YxAX a8bC0I5BbBPFgT5n0k1ZSoDay9nelvpYMWWK5vHfyf07V9+PqO4lTR4OJcWA+6mN+hjk WIDJ3WLOXaLqk7y45BdlxfVcT1B+grmOP0gZK7fd1tXGvSeGLc5qO9M0JSssPYRa4pj2 8v5wkkvzOl7jB/EK44bO70Yiy6YS2F3lVAhFNkxgZYGsxx+Bu1PVdNGhbHCcxQExjDAS d8wg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date :arc-authentication-results; bh=QfkF/g17/ICF8jP6X73W3lu6nSWlN3eFxkoBPer9Nro=; b=RFzwjXTvYPd+je58DVB++Nk9lobfbVkknClJrzMKo95dJm2RwuanRcESpRW0gy+BvD 3DeUsm5V7QIkNjBUStxPuQt181RqFEWZokKiUKiGMr5sNnXMEf8d0pKG0sVMW4XRwQoB t5TwRX5f+nlZDdli7sJd6N8GXgB+Ckh38KTVZ/x/M59RKdEocJc2sO30DM74x5qy+IKG JCAq5rV2JuxRA3kECvJlfrtBBpvE/6MUSl1HfZc/mh+JZOif5iwYCLn1yEmxI4N+TmlL pWB+zNnZL3pVCtcpdmwhlQ7Fpeg86SoQXaZgYy/N9WrMH6XN/+N6L8r7b3cP9FLa64FR Bxuw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s195si624345pgc.39.2018.02.27.23.18.42; Tue, 27 Feb 2018 23:18:56 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751675AbeB1HSE (ORCPT + 99 others); Wed, 28 Feb 2018 02:18:04 -0500 Received: from mx2.suse.de ([195.135.220.15]:38256 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750756AbeB1HSD (ORCPT ); Wed, 28 Feb 2018 02:18:03 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 27D64AD27; Wed, 28 Feb 2018 07:18:01 +0000 (UTC) Date: Wed, 28 Feb 2018 08:17:59 +0100 From: Michal Hocko To: Ilya Smith Cc: tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com, x86@kernel.org, kirill.shutemov@linux.intel.com, dsafonov@virtuozzo.com, hughd@google.com, gregkh@linuxfoundation.org, craigb@google.com, oleg@redhat.com, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH] Take mmap_min_addr into account while choosing unmapped address for x86-64. Message-ID: <20180228071759.GN15357@dhcp22.suse.cz> References: <20180226211257.63067-1-blackzert@gmail.com> <20180227085726.GC15357@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.3 (2018-01-21) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue 27-02-18 16:27:29, Ilya Smith wrote: > > > > mmap_min_addr handling is a bit mess... As you say, we would return > > EPERM rather than ENOMEM which can be confusing but depleting the > > address space like that is quite unlikely on 64b unless I am missing. > > It is good to be in sync here with the generic implementation though, > > IMO. > > > > If we take a look on mm/mmap.c: > #ifndef HAVE_ARCH_UNMAPPED_AREA_TOPDOWN > unsigned long > arch_get_unmapped_area_topdown( > … > if (len > TASK_SIZE - mmap_min_addr) > return -ENOMEM; > … > info.low_limit = max(PAGE_SIZE, mmap_min_addr); > > And this one looks like a generic implementation. > But for many other architectures like arch/parisc/kernel/sys_parisc.c > or arch/x86/kernel/sys_x86_64.c > > info.low_limit = PAGE_SIZE; Yeah, this is what I meant when saying that mmap_min_addr is a bit of a mess. I am wondering whether the low_limit should be checked inside vm_unmapped_area. We would still need some mmap_min_addr handling at arch_get_unmapped_area_topdown layer which is still suboptimal but I do not see an easy way around without reworking how the arch specific parts are implemented currently. -- Michal Hocko SUSE Labs