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

[David Woodhouse <dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 1477 bytes --]

On Fri, 2017-10-06 at 15:52 -0700, Dan Williams wrote:
> On Fri, Oct 6, 2017 at 3:45 PM, David Woodhouse <dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> wrote:
> > 
> > On Fri, 2017-10-06 at 15:35 -0700, Dan Williams wrote:
> > > 
> > > 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?

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 4938 bytes --]