Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933496AbbFJPhI (ORCPT ); Wed, 10 Jun 2015 11:37:08 -0400 Received: from mail-wi0-f176.google.com ([209.85.212.176]:37760 "EHLO mail-wi0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933156AbbFJPgv (ORCPT ); Wed, 10 Jun 2015 11:36:51 -0400 MIME-Version: 1.0 In-Reply-To: <20150610151100.GA12757@lst.de> References: <20150605205052.20751.77149.stgit@dwillia2-desk3.amr.corp.intel.com> <20150605211912.20751.35406.stgit@dwillia2-desk3.amr.corp.intel.com> <20150610121202.GA9190@lst.de> <20150610150334.GK2729@linux.intel.com> <20150610151100.GA12757@lst.de> Date: Wed, 10 Jun 2015 08:36:48 -0700 Message-ID: Subject: Re: [PATCH v4 2/9] x86: support kmap_atomic_pfn_t() for persistent memory From: Dan Williams To: Christoph Hellwig Cc: Matthew Wilcox , "linux-kernel@vger.kernel.org" , Jens Axboe , Boaz Harrosh , david , linux-arch@vger.kernel.org, Arnd Bergmann , Ross Zwisler , "linux-nvdimm@lists.01.org" , Benjamin Herrenschmidt , linux-fsdevel , Heiko Carstens , Tejun Heo , Paul Mackerras , "H. Peter Anvin" , Martin Schwidefsky , Andrew Morton , "torvalds@linux-foundation.org" , Ingo Molnar Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1389 Lines: 28 On Wed, Jun 10, 2015 at 8:11 AM, Christoph Hellwig wrote: > On Wed, Jun 10, 2015 at 11:03:35AM -0400, Matthew Wilcox wrote: >> On Wed, Jun 10, 2015 at 02:12:02PM +0200, Christoph Hellwig wrote: >> > Btw, I don't think this actually is safe without refcounting your kmap >> > structure. >> > >> > The driver model ->remove callback can be called at any time, which >> > will ioremap the memory and remap the kmap structure. But at this >> > point a user might still be using it. >> >> Won't the device data structures be pinned by the refcount on the bdev? > > An open filesystem only keeps a reference on the request_queue. The > underlying driver model ->remove method will still be called on > a surprise removal. On surprise removal my expectation is that the driver keeps the the ioremap mapping alive for at least a synchronize_rcu() period. With that in place the rcu_read_lock() in kmap_atomic_pfn_t() should keep the mapping alive for the short duration, or otherwise prevent new mappings. However, I missed converting the driver to order its iounmap() with respect to the pfn range registration via devres, will fix. -- 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/