Received: by 10.223.185.116 with SMTP id b49csp4949488wrg; Tue, 27 Feb 2018 05:29:13 -0800 (PST) X-Google-Smtp-Source: AH8x225mchAF0WCDYkAgvKmnJ/YJc3RHvfTaElmcjIRk480fG1bt4iD8Zu3VOGJT0OqlYC9jn6xw X-Received: by 2002:a17:902:24a5:: with SMTP id w34-v6mr14000422pla.221.1519738153797; Tue, 27 Feb 2018 05:29:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519738153; cv=none; d=google.com; s=arc-20160816; b=ag6iM6SR6mPSbjnNYYe9RZeC0exRIxAsfL1NSAA/1cvWaJn8ssIo644B4Ly/Z6Ly1D ApVz+MSSKpu+T+4FntgJb/l9/uK9IlYE1LREYFdmadtdzVb+k13/r82FvkCrjUfJsZ/n IwsoasZNSRQ+AXLzg1ZvgJ4I35XRna02ADF7wncR7mvTdrHteXOFpbVFrc5ekGXIf54W 7kjT8rLQZms2mirFqccrYOmmTXc6EP+Py/yb45GYGlJQi+E7Nd3n9paUbo6teCsUMtqs uM/DAHW+FvM+gCEUlN+ovC3FDb/YPjvL10zQ/GUi2yRZ0LW5GZPRdNtmjgnMffO8N3tB dHLQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:to:references:message-id :content-transfer-encoding:cc:date:in-reply-to:from:subject :mime-version:dkim-signature:arc-authentication-results; bh=qA+qlnepS59F3sVnKSg+EAXUhVpHV514cIJWLmw0WQE=; b=gwa9T5RMPMBVrmoiO3s8fjK7cCYqraAiEQM6i96EYiGxI+pChmXr+j/qaKY4idGhpi 9LGOcrU6ITHGadJzY6+B2Bx8nRoqz3SsGjEWcutJ5P7fFemU2VlKBXacdltX8j1qzXw0 /bnDVyqauiow9BgHWDB1JFRI9P1t/1odVDVAKKdhTZeJbJ99m9GjTvd/fvivgQU9cmm2 IDHfvwBYTlGxLSmGWWHcEU/7EbO61oyH8+43Tu6/BOyZiGXhHO7/4j+z2NbfnF4VUilY lGw9OG/24VKYthV046C/DJwslFvgTLpzWuJ8uNBfhJsykFPcyKolPIUvOtC4EV1m8M3P 8qpw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=eiE2iWDz; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c15-v6si7413378plz.630.2018.02.27.05.28.59; Tue, 27 Feb 2018 05:29:13 -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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=eiE2iWDz; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932096AbeB0N1d (ORCPT + 99 others); Tue, 27 Feb 2018 08:27:33 -0500 Received: from mail-lf0-f66.google.com ([209.85.215.66]:35542 "EHLO mail-lf0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753198AbeB0N1c (ORCPT ); Tue, 27 Feb 2018 08:27:32 -0500 Received: by mail-lf0-f66.google.com with SMTP id 70so27517609lfw.2 for ; Tue, 27 Feb 2018 05:27:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=qA+qlnepS59F3sVnKSg+EAXUhVpHV514cIJWLmw0WQE=; b=eiE2iWDzvSkN9318AADz10XHKCfPRR6MQp7QtkXMICo6gum52i1D24WfyKMa700xRG i+A2hxdj+I1jnpS+pUnwDI4Lol3WAOjhIyAvf3PvJqYkzg56wYC66b5z9zSDSkc1hC73 RcfeaDLX77eiskJrNuroyTv3ccQYioxGQ+Wato8tCZVU4B9lbcIAOQke0ItbAxh5Na+W 4yhy+2QK5vo/AIIo+O9t6ayQZU/qwcrQN0XtG7zfLuqfjych+ExTPeNEWPmOhxTP0ZKM QGeZrBVpm347p10vwy7Vephl0jZLZOHBiWOFoZBI44NpgIY8G/6WUZCdDTK6GFJrE32o xOxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=qA+qlnepS59F3sVnKSg+EAXUhVpHV514cIJWLmw0WQE=; b=tUruYsFzwR4b7nlLfXstLjfkQbzGJ4EyHIvXNKXvO2Z33qNPxn1HmKNiuUwzS9KeR1 AxOqOoRIoERJMXRygAhkWQ5PaRim9EUIqOyVg9uQsygUaIDgOczIBspqUf6VTV6BuF0i xpiQqoZuUJbKKpd60ilsUk7Fpx6Y8biqYkqFULg5XgJ4mmwEKFBaJS7JveUeuN1xHQiE B8AgHjzRIls0ZINVLhVCI5V22rd8v3N6r+Ow76OPzcBDy30uZbMxzOWfI8hQSYyw1fcS j3LXJC/9LlHvbwTqNWAnpa2UldC90j3t2j6jjRbp0vIB/MA/uBE1UqTueDu4/G2vJboc g6gw== X-Gm-Message-State: APf1xPAgv5gsOJn9yWx5anpti+NU50BmX1vvjQde61xv4virgwA4Rtug 14qOv1xXF3Ak+hGxnATU/MM= X-Received: by 10.46.81.25 with SMTP id f25mr10084088ljb.50.1519738050699; Tue, 27 Feb 2018 05:27:30 -0800 (PST) Received: from [10.0.36.159] ([31.44.93.2]) by smtp.gmail.com with ESMTPSA id y3sm2562774ljy.28.2018.02.27.05.27.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Feb 2018 05:27:29 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: [RFC PATCH] Take mmap_min_addr into account while choosing unmapped address for x86-64. From: Ilya Smith In-Reply-To: <20180227085726.GC15357@dhcp22.suse.cz> Date: Tue, 27 Feb 2018 16:27:29 +0300 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 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20180226211257.63067-1-blackzert@gmail.com> <20180227085726.GC15357@dhcp22.suse.cz> To: Michal Hocko X-Mailer: Apple Mail (2.3445.5.20) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org >=20 > 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. >=20 If we take a look on mm/mmap.c: #ifndef HAVE_ARCH_UNMAPPED_AREA_TOPDOWN unsigned long arch_get_unmapped_area_topdown( =E2=80=A6 if (len > TASK_SIZE - mmap_min_addr) return -ENOMEM; =E2=80=A6 info.low_limit =3D 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=20 or arch/x86/kernel/sys_x86_64.c info.low_limit =3D PAGE_SIZE; What is looks like an issue for me. Here is C code could be used as test-case: #include #include #include int main() { char buffer[1024]; unsigned long len =3D 1ULL << 46; while(len) { void *ptr =3D mmap(4096, len, 0, MAP_PRIVATE | MAP_ANONYMOUS , -1, = 0); if (ptr =3D=3D MAP_FAILED) { if (errno =3D=3D EPERM) break; if (errno =3D=3D ENOMEM) { len >>=3D 1; continue; } return -1; } } if (errno =3D=3D EPERM) { printf("Test failed, you have wrong ret code EPERM\n"); sprintf(buffer, "cat /proc/%d/maps", getpid()); system(buffer); return -1; } return 0; } >>=20 >> + if (addr < mmap_min_addr) >> + return false; >> + >> return (addr > DEFAULT_MAP_WINDOW) =3D=3D (addr + len > = DEFAULT_MAP_WINDOW); >=20 > But is this one necessary? We do sanitze hint address before going to > get_unmapped_address AFAIR. >=20 I=E2=80=99m agree, looks like I was trying to fix something that already = fine. Thanks, Ilya