From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751750AbcDZArx (ORCPT ); Mon, 25 Apr 2016 20:47:53 -0400 Received: from 216-12-86-13.cv.mvl.ntelos.net ([216.12.86.13]:57647 "EHLO brightrain.aerifal.cx" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750750AbcDZArv (ORCPT ); Mon, 25 Apr 2016 20:47:51 -0400 Date: Mon, 25 Apr 2016 20:47:45 -0400 From: Rich Felker To: Andrew Morton Cc: linux-kernel@vger.kernel.org, Michal Hocko , Greg Ungerer , Geert Uytterhoeven , Yoshinori Sato Subject: Re: [PATCH] tmpfs: fix VM_MAYSHARE mappings for NOMMU Message-ID: <20160426004744.GI21636@brightrain.aerifal.cx> References: <20160422221944.GA14264@brightrain.aerifal.cx> <20160425170909.31cf27c845a9fc19688fd5af@linux-foundation.org> <20160426004124.GH21636@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160426004124.GH21636@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 25, 2016 at 08:41:24PM -0400, Rich Felker wrote: > On Mon, Apr 25, 2016 at 05:09:09PM -0700, Andrew Morton wrote: > > On Fri, 22 Apr 2016 18:19:44 -0400 Rich Felker wrote: > > > > > Subject: [PATCH] tmpfs: fix VM_MAYSHARE mappings for NOMMU > > > > I take it that "ramfs" was intended here. > > They're two names for the same thing; I'm not sure which should be > preferred. Or maybe not... the relationship seems more complex, at least hisorically, but the ramfs code here is what seems to provide the backing for tmpfs (and maybe more?). Sorry for the quick and imprecise reply. Rich > > > The nommu do_mmap expects f_op->get_unmapped_area to either succeed or > > > return -ENOSYS for VM_MAYSHARE (e.g. private read-only) mappings. > > > Returning addr in the non-MAP_SHARED case was completely wrong, and > > > only happened to work because addr was 0. However, it prevented > > > VM_MAYSHARE mappings from sharing backing with the fs cache, and > > > forced such mappings (including shareable program text) to be copied > > > whenever the number of mappings transitioned from 0 to 1, impacting > > > performance and memory usage. Subsequent mappings beyond the first > > > still correctly shared memory with the first. > > > > > > Instead, treat VM_MAYSHARE identically to VM_SHARED at the file ops > > > level; do_mmap already handles the semantic differences between them. > > > > > > ... > > >