From 02ad0f4aca376902ddb5069d8362e1817c808c48 Mon Sep 17 00:00:00 2001 From: Patrick Daly Date: Mon, 13 Dec 2021 22:28:12 -0800 Subject: [PATCH] mem-buf: Add flush_delayed_fput() calls to recv kthread When a kernel thread calls dma_buf_put() to release the last reference to a dma-buf, fput_many() defers calling the release callback to a workqueue. This means that if the same kernel thread later calls dma_heap_buffer_alloc(), it has no guarantee that the memory from the prior free is available, leading to random failures. As a short-term workaround, call flush_delayed_fput() to ensure the free completes synchronously. Change-Id: Ia2ab97ca9d1adfb99cd20a316d412bf931f7b3f0 Signed-off-by: Patrick Daly --- drivers/soc/qcom/mem_buf/mem-buf-gh.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/soc/qcom/mem_buf/mem-buf-gh.c b/drivers/soc/qcom/mem_buf/mem-buf-gh.c index 8e145e37cd89..6bbd10ba1777 100644 --- a/drivers/soc/qcom/mem_buf/mem-buf-gh.c +++ b/drivers/soc/qcom/mem_buf/mem-buf-gh.c @@ -222,6 +222,13 @@ static void mem_buf_rmt_free_dmaheap_mem(struct mem_buf_xfer_mem *xfer_mem) dma_buf_unmap_attachment(attachment, mem_sgt, DMA_BIDIRECTIONAL); dma_buf_detach(dmabuf, attachment); dma_buf_put(dmaheap_mem_data->dmabuf); + /* + * No locks should be held at this point, as flush_delayed_fput may call the + * release callbacks of arbitrary files. It should be safe for us since we + * know this function is called only from our recv kthread, so we have control + * over what locks are currently held. + */ + flush_delayed_fput(); pr_debug("%s: DMAHEAP memory freed\n", __func__); }