From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Wed, 10 Jun 2015 14:12:02 +0200 From: Christoph Hellwig Subject: Re: [PATCH v4 2/9] x86: support kmap_atomic_pfn_t() for persistent memory Message-ID: <20150610121202.GA9190@lst.de> References: <20150605205052.20751.77149.stgit@dwillia2-desk3.amr.corp.intel.com> <20150605211912.20751.35406.stgit@dwillia2-desk3.amr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150605211912.20751.35406.stgit@dwillia2-desk3.amr.corp.intel.com> Sender: linux-fsdevel-owner@vger.kernel.org To: Dan Williams Cc: linux-kernel@vger.kernel.org, axboe@kernel.dk, boaz@plexistor.com, david@fromorbit.com, linux-arch@vger.kernel.org, arnd@arndb.de, ross.zwisler@linux.intel.com, linux-nvdimm@lists.01.org, benh@kernel.crashing.org, linux-fsdevel@vger.kernel.org, heiko.carstens@de.ibm.com, hch@lst.de, tj@kernel.org, paulus@samba.org, hpa@zytor.com, schwidefsky@de.ibm.com, willy@linux.intel.com, akpm@linux-foundation.org, torvalds@linux-foundation.org, mingo@kernel.org List-ID: 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.