From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dan Williams Subject: Re: [PATCH v6 3/5] mm: introduce mmap3 for safely defining new mmap flags Date: Thu, 24 Aug 2017 10:36:02 -0700 Message-ID: References: <150353211413.5039.5228914877418362329.stgit@dwillia2-desk3.amr.corp.intel.com> <150353213097.5039.6729469069608762658.stgit@dwillia2-desk3.amr.corp.intel.com> <20170824165546.GA3121@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: In-Reply-To: <20170824165546.GA3121-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Christoph Hellwig Cc: Andrew Morton , Jan Kara , Arnd Bergmann , "linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org" , Linux API , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , linux-xfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux MM , Andy Lutomirski , linux-fsdevel , "Kirill A. Shutemov" List-Id: linux-api@vger.kernel.org On Thu, Aug 24, 2017 at 9:55 AM, Christoph Hellwig wrote: > On Wed, Aug 23, 2017 at 04:48:51PM -0700, Dan Williams wrote: >> The mmap(2) syscall suffers from the ABI anti-pattern of not validating >> unknown flags. However, proposals like MAP_SYNC and MAP_DIRECT need a >> mechanism to define new behavior that is known to fail on older kernels >> without the support. Define a new mmap3 syscall that checks for >> unsupported flags at syscall entry and add a 'mmap_supported_mask' to >> 'struct file_operations' so generic code can validate the ->mmap() >> handler knows about the specified flags. This also arranges for the >> flags to be passed to the handler so it can do further local validation >> if the requested behavior can be fulfilled. > > What is the reason to not go with __MAP_VALID hack? Adding new > syscalls is extremely painful, it will take forever to trickle this > through all architectures (especially with the various 32-bit > architectures having all kinds of different granularities for the > offset) and then the various C libraries, never mind applications. I'll let Andy and Kirill restate their concerns, but one of the arguments that swayed me is that any new mmap flag with this hack must be documented to only work with MAP_SHARED and that MAP_PRIVATE is silently ignored. I agree with the mess and delays it causes for other archs and libc, but at the same time this is for new applications and libraries that know to look for the new flag, so they need to do the extra work to check for the new syscall. However, if the fcntl lease approach works for the DMA cases then we only have the one mmap flag to add for now, so maybe the weird MAP_{SHARED|PRIVATE} semantics are tolerable.