From: Helge Deller Subject: Re: [PATCH 01/18] mm: introduce MAP_SHARED_VALIDATE, a mechanism to safely define new mmap flags Date: Sat, 25 Nov 2017 19:45:21 +0100 Message-ID: <09f54d38-7cb5-343d-a017-2d71a793d05c@gmx.de> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: Vlastimil Babka , 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: Matthew Wilcox , Dan Williams Return-path: In-Reply-To: <20171122195318.GA29485@bombadil.infradead.org> Content-Language: en-US Sender: owner-linux-mm@kvack.org List-Id: linux-ext4.vger.kernel.org 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/ 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 -- 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