There are two cases:
1) In the normal case that the memory is being freed correctly, then
DMAPOOL_DEBUG will memset the memory anyway, so speed things up by
avoiding a double-memset of the same memory.
2) In the abnormal case that DMAPOOL_DEBUG detects that a driver passes
incorrect parameters to dma_pool_free() (e.g. double-free, invalid
free, mismatched vaddr/dma, etc.), then that is a kernel bug, and we
don't want to clear the passed-in possibly-invalid memory pointer
because we can't be sure that the memory is really free. So don't clear
it just because init_on_free=1.
Signed-off-by: Tony Battersby <to...@cybernetics.com>
---
mm/dmapool.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/mm/dmapool.c b/mm/dmapool.c
index 7a9161d4f7a6..49019ef6dd83 100644
--- a/mm/dmapool.c
+++ b/mm/dmapool.c
@@ -415,8 +415,6 @@ void dma_pool_free(struct dma_pool *pool, void *vaddr,
dma_addr_t dma)
}
offset = vaddr - page->vaddr;
- if (want_init_on_free())
- memset(vaddr, 0, pool->size);
#ifdef DMAPOOL_DEBUG
if ((dma - page->dma) != offset) {
spin_unlock_irqrestore(&pool->lock, flags);
@@ -461,6 +459,9 @@ void dma_pool_free(struct dma_pool *pool, void *vaddr,
dma_addr_t dma)
goto freelist_corrupt;
}
memset(vaddr, POOL_POISON_FREED, pool->size);
+#else
+ if (want_init_on_free())
+ memset(vaddr, 0, pool->size);
#endif
page->in_use--;
--
2.25.1
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
