From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933744AbbFJQRx (ORCPT ); Wed, 10 Jun 2015 12:17:53 -0400 Received: from mail-wi0-f173.google.com ([209.85.212.173]:36981 "EHLO mail-wi0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933591AbbFJQRl (ORCPT ); Wed, 10 Jun 2015 12:17:41 -0400 MIME-Version: 1.0 In-Reply-To: <20150610161157.GA14366@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> <20150610161157.GA14366@lst.de> Date: Wed, 10 Jun 2015 09:17:40 -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 On Wed, Jun 10, 2015 at 9:11 AM, Christoph Hellwig wrote: > On Wed, Jun 10, 2015 at 08:36:48AM -0700, Dan Williams wrote: >> 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. > > Right. I guess the best idea is to replace devm_register_kmap_pfn_range > with an interface that does the ioremap, in which case the cleanup > function can take care of the proper ordering behind the drivers back. Even better than what I was thinking... will do.