From: Konstantin Khlebnikov Subject: Re: [PATCH v2 1/3] pagemap: add mmap-exclusive bit for marking pages mapped only here Date: Fri, 15 May 2015 12:39:05 +0300 Message-ID: <5555BEB9.6000905@yandex-team.ru> References: <20150512090156.24768.2521.stgit@buzz> <20150512094303.24768.10282.stgit@buzz> <55532CB0.6070400@yandex-team.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Mark Williamson Cc: linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, Naoya Horiguchi , kernel list , Andrew Morton , Pavel Emelyanov , Linux API , Andy Lutomirski , Vlastimil Babka , Pavel Machek , Mark Seaborn , "Kirill A. Shutemov" , Linus Torvalds , Daniel James , Finn Grimwood List-Id: linux-api@vger.kernel.org On 14.05.2015 21:50, Mark Williamson wrote: > Hi Konstantin, > > On Wed, May 13, 2015 at 11:51 AM, Konstantin Khlebnikov > wrote: >> On 12.05.2015 15:05, Mark Williamson wrote: > >>> 1. I was hoping we'd be able to backport a compatible fix to older >>> kernels that might adopt the pagemap permissions change. Using the V2 >>> format flags rules out doing this for kernels that are too old to have >>> soft-dirty, I think. >>> >>> 2. From our software's PoV, I feel it's worth noting that it doesn't >>> strictly fix ABI compatibility, though I realise that's probably not >>> your primary concern here. We'll need to modify our code to write the >>> clear_refs file but that change is OK for us if it's the preferred >>> solution. > >> I prefer to backport v2 format (except soft-dirty bit and clear_refs) >> into older kernels. Page-shift bits are barely used so nobody will see >> the difference. > > My concern was whether a change to format would be acceptable to > include in the various -stable kernels; they are already including the > additional protections on pagemap, so we're starting to need our > fallback mode in distributions. Do you think that such a patch would > be acceptable there? > > (As an application vendor we're likely to be particularly stuck with > what the commercial distributions decide to ship, which is why I'm > trying to keep an eye on this) > > I appreciate that this is a slightly administrative concern! I > definitely like the technical approach of this code and it seems to > work fine for us. I cannot guarantee that v2 format will be accepted into stable kernels and into distributives. I'm not the gate keeper. As a fallback probably you should invent some kind of suid helper which gives you access to required information without exposing pfn. For example: it gets pids and memory ranges as arguments and prints bitmap of CoWed pages into stdout. -- Konstantin