staging: ion: ion_cma_heap: Don't directly use dma_common_get_sgtable

PATCH In review Jon Medhurst (Tixy) 3 participants 5 messages Jul 17, 2015 – Jul 20, 2015 Staging

Share & tools

Jon Medhurst (Tixy)

author

2015-07-17 11:01 UTC #0 lore raw

PATCH 1/1 staging: ion: ion_cma_heap: Don't directly use dma_common_get_sgtable

Use dma_get_sgtable rather than dma_common_get_sgtable so a device's dma_ops aren't bypassed. This is essential in situations where a device uses an IOMMU and the physical memory is not contiguous (as the common function assumes).

Signed-off-by Jon Medhurst <[email protected]>

---

This also begs the question as to what happens if the memory region _is_ contiguous but is in highmem or an ioremapped region. Should a device always provide dma_ops for that case? Because I believe the current implementation of dma_common_get_sgtable won't work for those as it uses virt_to_page.

I see that this point has been raised before [1] by Zeng Tao, and I myself have been given a different fix to apply to a Linaro kernel tree. However, both solutions looked wrong to me as they treat a dma_addr_t as a physical address, so should at least be using dma_to_phys.

So, should we fix dma_common_get_sgtable or mandate that the device has dma_ops? The latter seems to be implied by the commit message which introduced the function:

This patch provides a generic implementation based on virt_to_page() call. Architectures which require more sophisticated translation might provide their own get_sgtable() methods.

Note, I don't have a system where any of this code is used to test things, and have never looked at this area before yesterday, so I may have misunderstood what’s going on in the code.

[1] https://lkml.org/lkml/2014/12/1/584

 drivers/staging/android/ion/ion_cma_heap.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

drivers/staging/android/ion/ion_cma_heap.c +1 -2

index f4211f1..86b91fd 100644
@@ -73,8 +73,7 @@ static int ion_cma_allocate(struct ion_heap *heap, struct ion_buffer *buffer,
 	if (!info->table)
 		goto free_mem;
 
-	if (dma_common_get_sgtable
-	    (dev, info->table, info->cpu_addr, info->handle, len))
+	if (dma_get_sgtable(dev, info->table, info->cpu_addr, info->handle, len))
 		goto free_table;
 	/* keep this for memory release */
 	buffer->priv_virt = info;

Signature · 1 line

2.1.4

Robin Murphy

Reviewed-by on v1 1/1

2015-07-17 15:21 UTC #1 lore raw

Hi Tixy,

Quoted 6 lines · Jon Medhurst (Tixy)

Use dma_get_sgtable rather than dma_common_get_sgtable so a device's dma_ops aren't bypassed. This is essential in situations where a device uses an IOMMU and the physical memory is not contiguous (as the common function assumes).
Signed-off-by Jon Medhurst <[email protected]>

The lack of obvious users of this code makes it hard to tell if "dev" here is always the right, real, device pointer and never null or some dummy device with the wrong dma_ops, but the rest of the calls in this file are to the proper DMA API interface so at least this patch definitely makes things less wrong in that respect.

Reviewed-by Robin Murphy <[email protected]>

Quoted 16 lines

---
This also begs the question as to what happens if the memory region _is_ contiguous but is in highmem or an ioremapped region. Should a device always provide dma_ops for that case? Because I believe the current implementation of dma_common_get_sgtable won't work for those as it uses virt_to_page.
I see that this point has been raised before [1] by Zeng Tao, and I myself have been given a different fix to apply to a Linaro kernel tree. However, both solutions looked wrong to me as they treat a dma_addr_t as a physical address, so should at least be using dma_to_phys. So, should we fix dma_common_get_sgtable or mandate that the device has dma_ops? The latter seems to be implied by the commit message which introduced the function:

Quoted 4 lines

This patch provides a generic implementation based on virt_to_page() call. Architectures which require more sophisticated translation might provide their own get_sgtable() methods.

Given that we're largely here due to having poked this on arm64 systems, I'm inclined to think that implementing our own get_sgtable as per arch/arm is the right course of action. Since a lot of architectures using dma_common_get_sgtable don't even implement dma_to_phys, I don't think it would be right to try complicating the common code for a case that seems to be all but common. I can spin an arm64 patch if you like.

Robin.

Quoted 24 lines

Note, I don't have a system where any of this code is used to test things, and have never looked at this area before yesterday, so I may have misunderstood what’s going on in the code.
[1] https://lkml.org/lkml/2014/12/1/584
  drivers/staging/android/ion/ion_cma_heap.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)
drivers/staging/android/ion/ion_cma_heap.c +1 -2
index f4211f1..86b91fd 100644
@@ -73,8 +73,7 @@ static int ion_cma_allocate(struct ion_heap *heap, struct ion_buffer *buffer,
  	if (!info->table)
  		goto free_mem;
 
-	if (dma_common_get_sgtable
-	    (dev, info->table, info->cpu_addr, info->handle, len))
+	if (dma_get_sgtable(dev, info->table, info->cpu_addr, info->handle, len))
  		goto free_table;
  	/* keep this for memory release */
  	buffer->priv_virt = info;

Jon Medhurst (Tixy)

author

2015-07-17 16:29 UTC #2 lore raw

Quoted 19 lines · Robin Murphy

This also begs the question as to what happens if the memory region _is_
Quoted 13 lines
contiguous but is in highmem or an ioremapped region. Should a device always provide dma_ops for that case? Because I believe the current implementation of dma_common_get_sgtable won't work for those as it uses virt_to_page.
I see that this point has been raised before [1] by Zeng Tao, and I myself have been given a different fix to apply to a Linaro kernel tree. However, both solutions looked wrong to me as they treat a dma_addr_t as a physical address, so should at least be using dma_to_phys. So, should we fix dma_common_get_sgtable or mandate that the device has dma_ops? The latter seems to be implied by the commit message which introduced the function:
Quoted 4 lines
This patch provides a generic implementation based on virt_to_page() call. Architectures which require more sophisticated translation might provide their own get_sgtable() methods.

Quoted 4 lines

Given that we're largely here due to having poked this on arm64 systems, I'm inclined to think that implementing our own get_sgtable as per arch/arm is the right course of action. Since a lot of architectures using dma_common_get_sgtable don't even implement dma_to_phys,

I had another check and that seems to be true.

Quoted 3 lines

I don't
think it would be right to try complicating the common code for a case that seems to be all but common.

I'm inclined to agree, however I'm rather new to this area.

Quoted 1 line

I can spin an arm64 patch if you like.

That would be good. Especially as from what I see on the arm kernel lists you are already working in that area... And my inbox has just pinged with that patch from you, so I'll add a reference here [2] so people coming across this thread can find it easily.

For 32-bit arm my $subject patch should fix ION as that already has the DMA ops.

Signature · 4 lines

Tixy

[1] https://lkml.org/lkml/2014/12/1/584
[2] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/357561.html

Laura Abbott

2015-07-17 16:50 UTC #3 lore raw

In reply to Robin Murphy

Quoted 8 lines · Robin Murphy

Hi Tixy,
Quoted 5 lines · Jon Medhurst (Tixy)
Use dma_get_sgtable rather than dma_common_get_sgtable so a device's dma_ops aren't bypassed. This is essential in situations where a device uses an IOMMU and the physical memory is not contiguous (as the common function assumes).

Quoted 8 lines

Quoted 1 line
Signed-off-by Jon Medhurst <[email protected]>
The lack of obvious users of this code makes it hard to tell if "dev"
hereis always the right, real, device pointer and never null or some dummy device with the wrong dma_ops, but the rest of the calls in this file are to the proper DMA API interface so at least this patch definitely makes things less wrong in that respect.

Ion currently lacks any standard way to set up heaps and associate a device with a heap. This means it's basically a free for all for what devices get associated (getting something mainlined might help...). I agree that using the proper DMA APIs is a step in the right direction.

Quoted 23 lines

Reviewed-by Robin Murphy <[email protected]>
Quoted 16 lines
---
This also begs the question as to what happens if the memory region _is_ contiguous but is in highmem or an ioremapped region. Should a device always provide dma_ops for that case? Because I believe the current implementation of dma_common_get_sgtable won't work for those as it uses virt_to_page.
I see that this point has been raised before [1] by Zeng Tao, and I myself have been given a different fix to apply to a Linaro kernel tree. However, both solutions looked wrong to me as they treat a dma_addr_t as a physical address, so should at least be using dma_to_phys. So, should we fix dma_common_get_sgtable or mandate that the device has dma_ops? The latter seems to be implied by the commit message which introduced the function:
Quoted 4 lines
This patch provides a generic implementation based on virt_to_page() call. Architectures which require more sophisticated translation might provide their own get_sgtable() methods.

Quoted 7 lines

Given that we're largely here due to having poked this on arm64 systems,
I'm inclined to think that implementing our own get_sgtable as per arch/arm is the right course of action. Since a lot of architectures using dma_common_get_sgtable don't even implement dma_to_phys, I don't think it would be right to try complicating the common code for a case that seems to be all but common. I can spin an arm64 patch if you like.

This would be hit on any system that has non-coherent DMA or highmem. I'm not sure I agree this isn't a common case. How many of the other architectures are actually using the dma_get_sgtable and would have the potential to find a problem?

Thanks,
Laura

Robin Murphy

2015-07-20 18:30 UTC #4 lore raw

Hi Laura,

Quoted 19 lines · Laura Abbott

Quoted 8 lines · Robin Murphy
Hi Tixy,
Quoted 5 lines · Jon Medhurst (Tixy)
Use dma_get_sgtable rather than dma_common_get_sgtable so a device's dma_ops aren't bypassed. This is essential in situations where a device uses an IOMMU and the physical memory is not contiguous (as the common function assumes).
Quoted 8 lines
Quoted 1 line
Signed-off-by Jon Medhurst <[email protected]>
The lack of obvious users of this code makes it hard to tell if "dev"
hereis always the right, real, device pointer and never null or some dummy device with the wrong dma_ops, but the rest of the calls in this file are to the proper DMA API interface so at least this patch definitely makes things less wrong in that respect.

Quoted 4 lines

Ion currently lacks any standard way to set up heaps and associate a device with a heap. This means it's basically a free for all for what devices get associated (getting something mainlined might help...). I agree that using the proper DMA APIs is a step in the right direction.

I suspected as much, thanks for the confirmation.

Quoted 32 lines

Quoted 24 lines
Reviewed-by Robin Murphy <[email protected]>
Quoted 16 lines
---
This also begs the question as to what happens if the memory region _is_ contiguous but is in highmem or an ioremapped region. Should a device always provide dma_ops for that case? Because I believe the current implementation of dma_common_get_sgtable won't work for those as it uses virt_to_page.
I see that this point has been raised before [1] by Zeng Tao, and I myself have been given a different fix to apply to a Linaro kernel tree. However, both solutions looked wrong to me as they treat a dma_addr_t as a physical address, so should at least be using dma_to_phys. So, should we fix dma_common_get_sgtable or mandate that the device has dma_ops? The latter seems to be implied by the commit message which introduced the function:
Quoted 4 lines
This patch provides a generic implementation based on virt_to_page() call. Architectures which require more sophisticated translation might provide their own get_sgtable() methods.
Quoted 7 lines
Given that we're largely here due to having poked this on arm64 systems,
I'm inclined to think that implementing our own get_sgtable as per arch/arm is the right course of action. Since a lot of architectures using dma_common_get_sgtable don't even implement dma_to_phys, I don't think it would be right to try complicating the common code for a case that seems to be all but common. I can spin an arm64 patch if you like.

Quoted 4 lines

This would be hit on any system that has non-coherent DMA or highmem. I'm not sure I agree this isn't a common case. How many of the other architectures are actually using the dma_get_sgtable and would have the potential to find a problem?

This appears to be pretty much exclusively a graphics/video thing. Surveying in-tree callers (other than Ion) gives DRM, V4L, and a couple of specific ARM SoC drivers - my hunch is that none of those see much action on the likes of Blackfin and 68k.

That said, going through the git logs, the primary purpose of dma_common_get_sgtable would appear to be not breaking allmodconfig builds on architectures other than ARM. Thus I'm not really sure which is the least worst option - having "common" code which doesn't actually represent the common use case, or adding bogus dma_to_phys definitions to loads of architectures that don't even have proper DMA mapping implementations for the sake of some code they don't even use...

Robin.

Quoted 4 lines

Thanks,
Laura