Thread (49 messages) 49 messages, 9 authors, 2017-10-15

Re: [PATCH v7 07/12] dma-mapping: introduce dma_has_iommu()

From: David Woodhouse <hidden>
Date: 2017-10-06 23:10:34
Also in: linux-fsdevel, linux-mm, linux-rdma, linux-xfs, nvdimm

On Fri, 2017-10-06 at 15:52 -0700, Dan Williams wrote:
On Fri, Oct 6, 2017 at 3:45 PM, David Woodhouse [off-list ref] wrote:
quoted
On Fri, 2017-10-06 at 15:35 -0700, Dan Williams wrote:
quoted
Add a helper to determine if the dma mappings set up for a given device
are backed by an iommu. In particular, this lets code paths know that a
dma_unmap operation will revoke access to memory if the device can not
otherwise be quiesced. The need for this knowledge is driven by a need
to make RDMA transfers to DAX mappings safe. If the DAX file's block map
changes we need to be to reliably stop accesses to blocks that have been
freed or re-assigned to a new file.
"a dma_unmap operation revoke access to memory"... but it's OK that the
next *map* will give the same DMA address to someone else, right?
I'm assuming the next map will be to other physical addresses and a
different requester device since the memory is still registered
exclusively.
I meant the next map for this device/group.

It may well use the same virtual DMA address as the one you just
unmapped, yet actually map to a different physical address. So if the
DMA still occurs to the "old" address, that isn't revoked at all — it's
just going to the wrong physical location.

And if you are sure that the DMA will never happen, why do you need to
revoke the mapping in the first place?

Attachments

  • smime.p7s [application/x-pkcs7-signature] 4938 bytes
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help