From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752550AbdLGTOc (ORCPT ); Thu, 7 Dec 2017 14:14:32 -0500 Received: from mail-ua0-f195.google.com ([209.85.217.195]:36746 "EHLO mail-ua0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752501AbdLGTO3 (ORCPT ); Thu, 7 Dec 2017 14:14:29 -0500 X-Google-Smtp-Source: AGs4zMbYDsHB9kVCOV6DhyaHKmBAoZtXZ3PJRgbwOA/ZVpBYWPmkYIskzqpo98vJaW5R+GV8oSVIFXn8HX/SHL47MqY= MIME-Version: 1.0 In-Reply-To: <87bmjbks4c.fsf@concordia.ellerman.id.au> References: <20171129144219.22867-1-mhocko@kernel.org> <20171130065835.dbw4ajh5q5whikhf@dhcp22.suse.cz> <20171201152640.GA3765@rei> <87wp20e9wf.fsf@concordia.ellerman.id.au> <20171206045433.GQ26021@bombadil.infradead.org> <20171206070355.GA32044@bombadil.infradead.org> <87bmjbks4c.fsf@concordia.ellerman.id.au> From: Kees Cook Date: Thu, 7 Dec 2017 11:14:27 -0800 X-Google-Sender-Auth: 0Vbja-z6lwX7K38s_uZ6GFVSNig Message-ID: Subject: Re: [PATCH 0/2] mm: introduce MAP_FIXED_SAFE To: Michael Ellerman Cc: Matthew Wilcox , Cyril Hrubis , Michal Hocko , Linux API , Khalid Aziz , Andrew Morton , Russell King - ARM Linux , Andrea Arcangeli , Linux-MM , LKML , linux-arch , Florian Weimer , John Hubbard , Abdul Haleem , Joel Stanley , Pavel Machek Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Dec 6, 2017 at 9:46 PM, Michael Ellerman wrote: > Matthew Wilcox writes: > >> On Tue, Dec 05, 2017 at 08:54:35PM -0800, Matthew Wilcox wrote: >>> On Wed, Dec 06, 2017 at 03:51:44PM +1100, Michael Ellerman wrote: >>> > Cyril Hrubis writes: >>> > >>> > > Hi! >>> > >> > MAP_FIXED_UNIQUE >>> > >> > MAP_FIXED_ONCE >>> > >> > MAP_FIXED_FRESH >>> > >> >>> > >> Well, I can open a poll for the best name, but none of those you are >>> > >> proposing sound much better to me. Yeah, naming sucks... >>> > > >>> > > Given that MAP_FIXED replaces the previous mapping MAP_FIXED_NOREPLACE >>> > > would probably be a best fit. >>> > >>> > Yeah that could work. >>> > >>> > I prefer "no clobber" as I just suggested, because the existing >>> > MAP_FIXED doesn't politely "replace" a mapping, it destroys the current >>> > one - which you or another thread may be using - and clobbers it with >>> > the new one. >>> >>> It's longer than MAP_FIXED_WEAK :-P >>> >>> You'd have to be pretty darn strong to clobber an existing mapping. >> >> I think we're thinking about this all wrong. We shouldn't document it as >> "This is a variant of MAP_FIXED". We should document it as "Here's an >> alternative to MAP_FIXED". >> >> So, just like we currently say "exactly one of MAP_SHARED or MAP_PRIVATE", >> we could add a new paragraph saying "at most one of MAP_FIXED or >> MAP_REQUIRED" and "any of the following values". >> >> Now, we should implement MAP_REQUIRED as having each architecture >> define _MAP_NOT_A_HINT, and then #define MAP_REQUIRED (MAP_FIXED | >> _MAP_NOT_A_HINT), but that's not information to confuse users with. >> >> Also, that lets us add a third option at some point that is Yet Another >> Way to interpret the 'addr' argument, by having MAP_FIXED clear and >> _MAP_NOT_A_HINT set. >> >> I'm not set on MAP_REQUIRED. I came up with some awful names >> (MAP_TODDLER, MAP_TANTRUM, MAP_ULTIMATUM, MAP_BOSS, MAP_PROGRAM_MANAGER, >> etc). But I think we should drop FIXED from the middle of the name. > > MAP_REQUIRED doesn't immediately grab me, but I don't actively dislike > it either :) > > What about MAP_AT_ADDR ? > > It's short, and says what it does on the tin. The first argument to mmap > is actually called "addr" too. "FIXED" is supposed to do this too. Pavel suggested: MAP_ADD_FIXED (which is different from "use fixed", and describes why it would fail: can't add since it already exists.) Perhaps "MAP_FIXED_NEW"? There has been a request to drop "FIXED" from the name, so these: MAP_FIXED_NOCLOBBER MAP_FIXED_NOREPLACE MAP_FIXED_ADD MAP_FIXED_NEW Could be: MAP_NOCLOBBER MAP_NOREPLACE MAP_ADD MAP_NEW and we still have the unloved, but acceptable: MAP_REQUIRED My vote is still for "NOREPLACE" or "NOCLOBBER" since it's very specific, though "NEW" is pretty clear too. -Kees -- Kees Cook Pixel Security From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kees Cook Subject: Re: [PATCH 0/2] mm: introduce MAP_FIXED_SAFE Date: Thu, 7 Dec 2017 11:14:27 -0800 Message-ID: References: <20171129144219.22867-1-mhocko@kernel.org> <20171130065835.dbw4ajh5q5whikhf@dhcp22.suse.cz> <20171201152640.GA3765@rei> <87wp20e9wf.fsf@concordia.ellerman.id.au> <20171206045433.GQ26021@bombadil.infradead.org> <20171206070355.GA32044@bombadil.infradead.org> <87bmjbks4c.fsf@concordia.ellerman.id.au> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: In-Reply-To: <87bmjbks4c.fsf@concordia.ellerman.id.au> Sender: owner-linux-mm@kvack.org To: Michael Ellerman Cc: Matthew Wilcox , Cyril Hrubis , Michal Hocko , Linux API , Khalid Aziz , Andrew Morton , Russell King - ARM Linux , Andrea Arcangeli , Linux-MM , LKML , linux-arch , Florian Weimer , John Hubbard , Abdul Haleem , Joel Stanley , Pavel Machek List-Id: linux-api@vger.kernel.org On Wed, Dec 6, 2017 at 9:46 PM, Michael Ellerman wrote: > Matthew Wilcox writes: > >> On Tue, Dec 05, 2017 at 08:54:35PM -0800, Matthew Wilcox wrote: >>> On Wed, Dec 06, 2017 at 03:51:44PM +1100, Michael Ellerman wrote: >>> > Cyril Hrubis writes: >>> > >>> > > Hi! >>> > >> > MAP_FIXED_UNIQUE >>> > >> > MAP_FIXED_ONCE >>> > >> > MAP_FIXED_FRESH >>> > >> >>> > >> Well, I can open a poll for the best name, but none of those you are >>> > >> proposing sound much better to me. Yeah, naming sucks... >>> > > >>> > > Given that MAP_FIXED replaces the previous mapping MAP_FIXED_NOREPLACE >>> > > would probably be a best fit. >>> > >>> > Yeah that could work. >>> > >>> > I prefer "no clobber" as I just suggested, because the existing >>> > MAP_FIXED doesn't politely "replace" a mapping, it destroys the current >>> > one - which you or another thread may be using - and clobbers it with >>> > the new one. >>> >>> It's longer than MAP_FIXED_WEAK :-P >>> >>> You'd have to be pretty darn strong to clobber an existing mapping. >> >> I think we're thinking about this all wrong. We shouldn't document it as >> "This is a variant of MAP_FIXED". We should document it as "Here's an >> alternative to MAP_FIXED". >> >> So, just like we currently say "exactly one of MAP_SHARED or MAP_PRIVATE", >> we could add a new paragraph saying "at most one of MAP_FIXED or >> MAP_REQUIRED" and "any of the following values". >> >> Now, we should implement MAP_REQUIRED as having each architecture >> define _MAP_NOT_A_HINT, and then #define MAP_REQUIRED (MAP_FIXED | >> _MAP_NOT_A_HINT), but that's not information to confuse users with. >> >> Also, that lets us add a third option at some point that is Yet Another >> Way to interpret the 'addr' argument, by having MAP_FIXED clear and >> _MAP_NOT_A_HINT set. >> >> I'm not set on MAP_REQUIRED. I came up with some awful names >> (MAP_TODDLER, MAP_TANTRUM, MAP_ULTIMATUM, MAP_BOSS, MAP_PROGRAM_MANAGER, >> etc). But I think we should drop FIXED from the middle of the name. > > MAP_REQUIRED doesn't immediately grab me, but I don't actively dislike > it either :) > > What about MAP_AT_ADDR ? > > It's short, and says what it does on the tin. The first argument to mmap > is actually called "addr" too. "FIXED" is supposed to do this too. Pavel suggested: MAP_ADD_FIXED (which is different from "use fixed", and describes why it would fail: can't add since it already exists.) Perhaps "MAP_FIXED_NEW"? There has been a request to drop "FIXED" from the name, so these: MAP_FIXED_NOCLOBBER MAP_FIXED_NOREPLACE MAP_FIXED_ADD MAP_FIXED_NEW Could be: MAP_NOCLOBBER MAP_NOREPLACE MAP_ADD MAP_NEW and we still have the unloved, but acceptable: MAP_REQUIRED My vote is still for "NOREPLACE" or "NOCLOBBER" since it's very specific, though "NEW" is pretty clear too. -Kees -- Kees Cook Pixel Security -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org