On Wed, Jun 10, 2015 at 8:11 AM, Christoph Hellwig <hch@xxxxxx> 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-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
