From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jann Horn Subject: Re: [PATCH] mmap.2: MAP_FIXED is okay if the address range has been reserved Date: Mon, 16 Apr 2018 22:17:40 +0200 Message-ID: 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> <20180416195726.GT17484@dhcp22.suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: In-Reply-To: <20180416195726.GT17484@dhcp22.suse.cz> Sender: linux-kernel-owner@vger.kernel.org To: Michal Hocko Cc: "Michael Kerrisk (man-pages)" , John Hubbard , linux-man , Andrew Morton , Linux-MM , lkml , Linux API List-Id: linux-api@vger.kernel.org On Mon, Apr 16, 2018 at 9:57 PM, Michal Hocko wrote: > On Mon 16-04-18 21:30:09, Jann Horn wrote: >> On Mon, Apr 16, 2018 at 9:18 PM, Michal Hocko wrote: > [...] >> > 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; > > Any other thread can modify the address space at this moment. But not parts of the address space that were returned by this mmap() call. > Just > consider that another thread would does mmap(x, MAP_FIXED) (or any other > address overlapping [x, x+len] range) If the other thread does that without previously having created a mapping covering the area in question, that would be a bug in the other thread. MAP_FIXED on an unmapped address is almost always a bug (excluding single-threaded cases with no library code, and even then it's quite weird) - for example, any malloc() call could also cause libc to start using the memory range you're trying to map with MAP_FIXED. > becaus it is seemingly safe as x > != hint. I don't understand this part. Are you talking about a hypothetical scenario in which a programmer attempts to segment the virtual memory space into areas that are exclusively used by threads without creating memory mappings for those areas? > This will succeed and ... >> munmap(x, len); > ... now you are munmaping somebody's else memory range > >> return NULL; > > Do code _is_ buggy but it is not obvious at all. > >> } >> >> has no need for any form of external synchronization. > > If the above mmap/munmap section was protected by a lock and _all_ other > mmaps (direct or indirect) would use the same lock then you are safe > against that.