From: Vlastimil Babka Subject: Re: [PATCH 01/18] mm: introduce MAP_SHARED_VALIDATE, a mechanism to safely define new mmap flags Date: Mon, 27 Nov 2017 16:55:54 +0100 Message-ID: <35fa2cb6-9957-fd77-836c-760cecc64b2e@suse.cz> References: <20171101153648.30166-1-jack@suse.cz> <20171101153648.30166-2-jack@suse.cz> <638b3b80-5cb9-97c2-5055-fef3a1ec25b9@suse.cz> <20171122195318.GA29485@bombadil.infradead.org> <09f54d38-7cb5-343d-a017-2d71a793d05c@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: Jan Kara , Ross Zwisler , Christoph Hellwig , linux-fsdevel , "linux-nvdimm@lists.01.org" , Linux MM , Linux API , linux-ext4 , linux-xfs , "Darrick J . Wong" , Arnd Bergmann , Andy Lutomirski , Andrew Morton , Michal Hocko , Kees Cook , Florian Weimer , John Hubbard , "Kirill A. Shutemov" , linux-parisc@vger.kernel.org To: Helge Deller , Matthew Wilcox , Dan Williams Return-path: In-Reply-To: <09f54d38-7cb5-343d-a017-2d71a793d05c@gmx.de> Content-Language: en-US Sender: linux-parisc-owner@vger.kernel.org List-Id: linux-ext4.vger.kernel.org On 11/25/2017 07:45 PM, Helge Deller wrote: > On 22.11.2017 20:53, Matthew Wilcox wrote: >> On Wed, Nov 22, 2017 at 08:52:37AM -0800, Dan Williams wrote: >>> On Wed, Nov 22, 2017 at 4:02 AM, Vlastimil Babka wrote: >>>> On 11/01/2017 04:36 PM, Jan Kara wrote: >>>>> From: Dan Williams >>>>> >>>>> The mmap(2) syscall suffers from the ABI anti-pattern of not validating >>>>> unknown flags. However, proposals like MAP_SYNC need a mechanism to >>>>> define new behavior that is known to fail on older kernels without the >>>>> support. Define a new MAP_SHARED_VALIDATE flag pattern that is >>>>> guaranteed to fail on all legacy mmap implementations. >>>> >>>> So I'm trying to make sense of this together with Michal's attempt for >>>> MAP_FIXED_SAFE [1] where he has to introduce a completely new flag >>>> instead of flag modifier exactly for the reason of not validating >>>> unknown flags. And my conclusion is that because MAP_SHARED_VALIDATE >>>> implies MAP_SHARED and excludes MAP_PRIVATE, MAP_FIXED_SAFE as a >>>> modifier cannot build on top of this. Wouldn't thus it be really better >>>> long-term to introduce mmap3 at this point? ... >>> >>> We have room to define MAP_PRIVATE_VALIDATE in MAP_TYPE on every arch >>> except parisc. Can we steal an extra bit for MAP_TYPE from somewhere >>> else on parisc? >> >> It looks like 0x08 should work. > > I posted an RFC to the parisc mailing list for that: > https://patchwork.kernel.org/patch/9970553/ Thanks. BTW there doesn't seem to be much interest making MAP_FIXED_SAFE a flag modifier after all, so MAP_PRIVATE_VALIDATE wouldn't get immediate users. > Basically this is (for parisc only): > -#define MAP_TYPE 0x03 /* Mask for type of mapping */ > +#define MAP_TYPE (MAP_SHARED|MAP_PRIVATE|MAP_RESRVD1|MAP_RESRVD2) /* Mask for type of mapping */ > #define MAP_FIXED 0x04 /* Interpret addr exactly */ > +#define MAP_RESRVD1 0x08 /* reserved for 3rd bit of MAP_TYPE */ > #define MAP_ANONYMOUS 0x10 /* don't use a file */ > +#define MAP_RESRVD2 0x20 /* reserved for 4th bit of MAP_TYPE */ > >> But I don't have an HPUX machine around >> to check that HP didn't use that bit for something else. > > We completely dropped support for HPUX binaries, so it's not relvant any longer. > >> It'd probably help to cc the linux-parisc mailing list when asking >> questions about PARISC, eh? > > Yes, please. > > Helge >