Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752955AbbH0Hd2 (ORCPT ); Thu, 27 Aug 2015 03:33:28 -0400 Received: from verein.lst.de ([213.95.11.211]:43798 "EHLO newverein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752182AbbH0Hd1 (ORCPT ); Thu, 27 Aug 2015 03:33:27 -0400 Date: Thu, 27 Aug 2015 09:33:25 +0200 From: "hch@lst.de" To: "Williams, Dan J" Cc: "hch@lst.de" , "linux-kernel@vger.kernel.org" , "mingo@kernel.org" , "linux-mm@kvack.org" , "hpa@zytor.com" , "linux-nvdimm@lists.01.org" , "ross.zwisler@linux.intel.com" , "boaz@plexistor.com" , "david@fromorbit.com" Subject: Re: [PATCH v2 9/9] devm_memremap_pages: protect against pmem device unbind Message-ID: <20150827073325.GB27207@lst.de> References: <20150826010220.8851.18077.stgit@dwillia2-desk3.amr.corp.intel.com> <20150826012813.8851.35482.stgit@dwillia2-desk3.amr.corp.intel.com> <20150826124649.GA8014@lst.de> <1440625157.31365.21.camel@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1440625157.31365.21.camel@intel.com> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1451 Lines: 35 On Wed, Aug 26, 2015 at 09:39:18PM +0000, Williams, Dan J wrote: > On Wed, 2015-08-26 at 14:46 +0200, Christoph Hellwig wrote: > > On Tue, Aug 25, 2015 at 09:28:13PM -0400, Dan Williams wrote: > > > Given that: > > > > > > 1/ device ->remove() can not be failed > > > > > > 2/ a pmem device may be unbound at any time > > > > > > 3/ we do not know what other parts of the kernel are actively using a > > > 'struct page' from devm_memremap_pages() > > > > > > ...provide a facility for active usages of device memory to block pmem > > > device unbind. With a percpu_ref it should be feasible to take a > > > reference on a per-I/O or other high frequency basis. > > > > Without a caller of get_page_map this is just adding dead code. I'd > > suggest to group it in a series with that caller. > > > > Agreed, we can drop this until the first user arrives. > > > Also if the page_map gets exposed in a header the name is a bit too generic. > > memremap_map maybe? > > Done, and in the patch below I hide the internal implementation details > of page_map in kernel/memremap.c and only expose the percpu_ref in the > public memremap_map. Yes, that looks good once we're getting the users for it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/