Re: [PATCH v4 2/9] x86: support kmap_atomic_pfn_t() for persistent memory

[Dan Williams]

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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/