Displaying 3 results from an estimated 3 matches for "781ca2de89ba".
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
2023 Jan 20
0
[PATCH v2 04/10] iommu/dma: Use the gfp parameter in __iommu_dma_alloc_noncontiguous()
...ing 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 been
an oversight in 781ca2de89ba, since this particular path has never
supported being called in atomic context.
Overall I'm starting to wonder if it might not be better to stick a "use
GFP_KERNEL_ACCOUNT if you allocate" flag in the domain for any level of
the API internals to pick up as appropriate, rather than...