Received: by 10.192.165.156 with SMTP id m28csp1015843imm; Mon, 16 Apr 2018 12:32:21 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+F/Exki7HacZyumIayKzg/TKYRxuJMQvKTMgkHxhZ78IcxFc7QckCXBOFyE2Xw5kvm7xqS X-Received: by 10.99.171.11 with SMTP id p11mr13663548pgf.176.1523907140998; Mon, 16 Apr 2018 12:32:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523907140; cv=none; d=google.com; s=arc-20160816; b=FzSPTW46F1Wk3nVDfzmchcM75e6HerbBd7Ttt2kHimlEqXtUquvLSdTzus7EUjqv6d pvO9V8yDXnW9KUe8N1tBYtyx6C5hOgPAcfWJVhzv+6LFrcFT0+uYmH4QmD+idyMqLD0o eI5r3Aoroqgz9doyvQ49OT286bKJXZxDeMui2wGL8ciHs69fjhkxaLbdJ0dAzeAFs9FZ EMyLSIeBBnaj8NhQh19vXq/SO5vcZwQppcXmSx7dfJXoWnTv1tfnjveriDVQz9zpVojJ ZdEFN3LZ9KKv3vuD7B0uWy30istMBYv1q8R/+uogSR4apUn3gyafrI2RqfXw4b6SzQBE obRQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=oWkfiaRoUCqGEWBW21RKoLAhVL1lDBJRPySWica2tpA=; b=YOzjIfqcOEXfl1kDz7GAt2xfKDkb8cNCm/oKqrWsRK8HwbZpCSb7xRMNYdF51X/Csn ePsOBYozCA3svqIw/zD9PehXACvkjnQ5xeFJa+2uiGaZRieL8fMg+jVNCAh/A0mfsPVW WmVu5+x7TTcvPvizX2V78G0mo6NqWyKiYa6gBTenLG6MgFCiwMHDbhBnq4CRM8AF27kp 6iqkRY2XfJDF6/fIHR6oqd8YHGRTqHiDsmHjNOzssXpv26BqcItD+BZgq+5aYooX4lB8 0TeulEFSBLqMk8z8drHBwz/JtVjLNeTtkREUunb8qw83zATlaYK99WBEYPp95mx1aHtY h5+g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=I+SRcEpp; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a5-v6si11958738plp.196.2018.04.16.12.32.07; Mon, 16 Apr 2018 12:32:20 -0700 (PDT) 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=@google.com header.s=20161025 header.b=I+SRcEpp; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753464AbeDPTad (ORCPT + 99 others); Mon, 16 Apr 2018 15:30:33 -0400 Received: from mail-oi0-f41.google.com ([209.85.218.41]:41739 "EHLO mail-oi0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752308AbeDPTab (ORCPT ); Mon, 16 Apr 2018 15:30:31 -0400 Received: by mail-oi0-f41.google.com with SMTP id 188-v6so15663162oih.8 for ; Mon, 16 Apr 2018 12:30:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oWkfiaRoUCqGEWBW21RKoLAhVL1lDBJRPySWica2tpA=; b=I+SRcEppsGba+uhkkMDOUqJTurIot/8PtUQZ6DgSyvoXrxVXVcu+z0iM1DHeV9ydc/ ROxoMTH8KzBpaJVfsuy+15V7g4Otp7mVc7TTBrXyYwmOgOuWrt8bNbBkjdX4pJk7ZMrg EXrMeYAiRLisCY/jLKYzzTY1f4VN2H6U4sUtMPuOX4MsgWeUFKm+d9YTt/9QpyjzJgSp puzSnKOLlUYXse73MUfxDZVYeihytAjLlmoT3Yrn7u7dKmAvrdDFPOdHTSjaXHDyD9cy nvYnbJIOjrc/uXEppEMiAZCLeiXbbtyGrpsZsU+GYtyArpAqiTOPpkgYKxCdZgMaIoIM Ln1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oWkfiaRoUCqGEWBW21RKoLAhVL1lDBJRPySWica2tpA=; b=VklCaykjPpguYbkAlLQeznI/dwLEdwsqO9zUSXZUswDFiXyRcrLi2e6pAYAXuBLrmv biEIxvgIIREwvuhzw/QsKdwh+fxsyxuR/MbTWS/e9HHyebibzKwxhDkI8zfc2npr0mzY FdPrnilRkTlZNivY+IVgOYMEc0mjcNVk1SHiuYCUb81qK1NrUsqGeVmDlm5rnBLtoByp xSKfN71yeTyRDplB8Yi8UAu+gIR6youw22z09hbtFkaq+CNQokrc46n1IKd3swf4pTnk 77M3Hsjz7Hj+vIREilPAQ5As2Aebh3JE5YWUGfUMGCWDQLt2q785TjcX6ADKefJC+4G0 4B+Q== X-Gm-Message-State: ALQs6tA0fbveIU+BgEUwdvzSEp13TCJ8wWEs5T2xzWdYRZRoq7jSVYw9 Kpl5siXa4dQZheN3OpHxdOcDBkBLRvj3wJBSUkLJLQ== X-Received: by 2002:aca:5484:: with SMTP id i126-v6mr14625530oib.219.1523907029994; Mon, 16 Apr 2018 12:30:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.158.88 with HTTP; Mon, 16 Apr 2018 12:30:09 -0700 (PDT) In-Reply-To: <20180416191805.GS17484@dhcp22.suse.cz> References: <9c714917-fc29-4d12-b5e8-cff28761a2c1@gmail.com> <20180413064917.GC17484@dhcp22.suse.cz> <20180413160435.GA17484@dhcp22.suse.cz> <20180416100736.GG17484@dhcp22.suse.cz> <20180416191805.GS17484@dhcp22.suse.cz> From: Jann Horn Date: Mon, 16 Apr 2018 21:30:09 +0200 Message-ID: Subject: Re: [PATCH] mmap.2: MAP_FIXED is okay if the address range has been reserved To: Michal Hocko Cc: "Michael Kerrisk (man-pages)" , John Hubbard , linux-man , Andrew Morton , Linux-MM , lkml , Linux API Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 16, 2018 at 9:18 PM, Michal Hocko wrote: > On Mon 16-04-18 15:55:36, Jann Horn wrote: >> On Mon, Apr 16, 2018 at 12:07 PM, Michal Hocko wrote: >> > On Fri 13-04-18 18:17:36, Jann Horn wrote: >> >> On Fri, Apr 13, 2018 at 6:05 PM, Jann Horn wrote: >> >> > On Fri, Apr 13, 2018 at 6:04 PM, Michal Hocko wrote: >> >> >> On Fri 13-04-18 17:04:09, Jann Horn wrote: >> >> >>> On Fri, Apr 13, 2018 at 8:49 AM, Michal Hocko wrote: >> >> >>> > On Fri 13-04-18 08:43:27, Michael Kerrisk wrote: >> >> >>> > [...] >> >> >>> >> So, you mean remove this entire paragraph: >> >> >>> >> >> >> >>> >> For cases in which the specified memory region has not been >> >> >>> >> reserved using an existing mapping, newer kernels (Linux >> >> >>> >> 4.17 and later) provide an option MAP_FIXED_NOREPLACE that >> >> >>> >> should be used instead; older kernels require the caller to >> >> >>> >> use addr as a hint (without MAP_FIXED) and take appropriate >> >> >>> >> action if the kernel places the new mapping at a different >> >> >>> >> address. >> >> >>> >> >> >> >>> >> It seems like some version of the first half of the paragraph is worth >> >> >>> >> keeping, though, so as to point the reader in the direction of a remedy. >> >> >>> >> How about replacing that text with the following: >> >> >>> >> >> >> >>> >> Since Linux 4.17, the MAP_FIXED_NOREPLACE flag can be used >> >> >>> >> in a multithreaded program to avoid the hazard described >> >> >>> >> above. >> >> >>> > >> >> >>> > Yes, that sounds reasonable to me. >> >> >>> >> >> >>> But that kind of sounds as if you can't avoid it before Linux 4.17, >> >> >>> when actually, you just have to call mmap() with the address as hint, >> >> >>> and if mmap() returns a different address, munmap() it and go on your >> >> >>> normal error path. >> >> >> >> >> >> This is still racy in multithreaded application which is the main point >> >> >> of the whole section, no? >> >> > >> >> > No, it isn't. >> > >> > I could have been more specific, sorry. >> > >> >> mmap() with a hint (without MAP_FIXED) will always non-racily allocate >> >> a memory region for you or return an error code. If it does allocate a >> >> memory region, it belongs to you until you deallocate it. It might be >> >> at a different address than you requested - >> > >> > Yes, this all is true. Except the atomicity is guaranteed only for the >> > syscall. Once you return to the userspace any error handling is error >> > prone and racy because your mapping might change under you feet. So... >> >> Can you please elaborate on why you think anything could change the >> mapping returned by mmap() under the caller's feet? > > Because as soon as the mmap_sem is dropped then any other thread can > modify the shared address space. > >> When mmap() returns a memory area to the caller, that memory area >> belongs to the caller. No unrelated code will touch it, unless that >> code is buggy. > > Yes, reasonably well written application will not have this problem. > That, however, requires an external synchronization and that's why > called it error prone and racy. I guess that was the main motivation for > that part of the man page. What requires external synchronization? I still don't understand at all what you're talking about. The following code: void *try_to_alloc_addr(void *hint, size_t len) { char *x = mmap(hint, len, ...); if (x == MAP_FAILED) return NULL; if (x == hint) return x; munmap(x, len); return NULL; } has no need for any form of external synchronization. You can call it in library code, you can call it in a multithreaded process, you can call it wherever and it should be safe. mmap() atomically reserves previously unallocated memory, and nothing else should be touching that memory until it is released again using munmap(). (Just like malloc(): When you call malloc(), you get a chunk of memory that is reserved just for you, and nobody else will scribble over it until you call free().)