Displaying 3 results from an estimated 3 matches for "sg_kmalloc".
Did you mean:
__kmalloc
2023 Jan 20
0
[PATCH v2 04/10] iommu/dma: Use the gfp parameter in __iommu_dma_alloc_noncontiguous()
...have been that the sgtable metadata is a
logically-distinct allocation from the buffer pages themselves. Much
like the allocation of the pages array itself further down in
__iommu_dma_alloc_pages(). I see these days it wouldn't be catastrophic
to pass GFP_HIGHMEM into __get_free_page() via sg_kmalloc(), but still,
allocating implementation-internal metadata with all the same
constraints as a DMA buffer has just as much smell of wrong about it IMO.
I'd say the more confusing thing about this particular context is why
we're using iommu_map_sg_atomic() further down - that seems to have...
2023 Jan 18
4
[PATCH v2 04/10] iommu/dma: Use the gfp parameter in __iommu_dma_alloc_noncontiguous()
Change the sg_alloc_table_from_pages() allocation that was hardwired to
GFP_KERNEL to use the gfp parameter like the other allocations in this
function.
Auditing says this is never called from an atomic context, so it is safe
as is, but reads wrong.
Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>
---
drivers/iommu/dma-iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
2023 Jan 18
4
[PATCH v2 04/10] iommu/dma: Use the gfp parameter in __iommu_dma_alloc_noncontiguous()
Change the sg_alloc_table_from_pages() allocation that was hardwired to
GFP_KERNEL to use the gfp parameter like the other allocations in this
function.
Auditing says this is never called from an atomic context, so it is safe
as is, but reads wrong.
Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>
---
drivers/iommu/dma-iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff