kernel/git/next/linux-next.git/drivers/dma/dmaengine.c, branch master

dmaengine: wait for RCU readers before releasing dma_device

2026-09-09T12:21:44+00:00

dma_issue_pending_all() walks the dma_device_list with list_for_each_entry_rcu() under rcu_read_lock(). dma_device_release() unlinks the device with list_del_rcu() and then calls device->device_release() (which in many drivers, such as plx_dma.c, directly calls kfree()). Because there is no grace period between unlinking the device and freeing it, concurrent RCU readers in dma_issue_pending_all() can access the device after it has been freed. The lockless walk originally relied on clients holding a dmaengine reference to pin the provider module, and therefore the device, for as long as they might traverse the list. Commit 8ad342a86359 ("dmaengine: Add reference counting to dma_device struct") decoupled the dma_device lifetime from the module reference, so the device can now be released while a reader is still walking the list. Add synchronize_rcu() before the device is freed, so RCU readers are guaranteed to have finished. Keep it unconditional: providers that do not implement device_release() free the device themselves once dma_async_device_unregister() returns. This call will delay for a grace period with dma_list_mutex held, which is safe and only teardown path is delayed. Fixes: 2ba05622b8b1 ("dmaengine: provide a common 'issue_pending_all' implementation") Suggested-by: Sashiko Link: https://sashiko.dev/#/patchset/20260526-dmaengine-kref-fix-v2-0-3df60afac01d@amd.com Reviewed-by: Frank Li Reviewed-by: Logan Gunthorpe Signed-off-by: Shivank Garg Link: https://patch.msgid.link/20260822-dmaengine-kref-fix-v5-4-d4a4ee47d927@amd.com Signed-off-by: Vinod Koul

dmaengine: fix use-after-free in dma_chan_put() and dma_release_channel()

2026-09-09T12:21:44+00:00

When dma_device_put() drops the last reference on chan->device->ref, dma_device_release() runs and may free the dma_device along with its channels. dma_chan_put() then still reads chan->device->owner via dma_chan_to_owner() for the trailing module_put(). KASAN catches it: slab-use-after-free in dma_chan_put+0x3e6/0x4c0 Read of size 8 by task insmod/6319 Freed by task 6319: kfree+0x225/0x470 dma_chan_put+0x395/0x4c0 dmaengine_put+0xf8/0x160 Cache the module owner in dma_chan_put() before the put so the trailing module_put() does not need chan->device. Fixes: 8ad342a86359 ("dmaengine: Add reference counting to dma_device struct") Suggested-by: Sashiko Link: https://sashiko.dev/#/patchset/20260518-dmaengine-kref-fix-v1-1-4d6125048fb7@amd.com Reviewed-by: Frank Li Reviewed-by: Logan Gunthorpe Signed-off-by: Shivank Garg Link: https://patch.msgid.link/20260822-dmaengine-kref-fix-v5-3-d4a4ee47d927@amd.com Signed-off-by: Vinod Koul

dmaengine: Fix device kref underflow in dma_chan_put()

2026-09-09T12:21:44+00:00

dma_chan_get() takes chan->device->ref only on the slow path: /* no kref on fast path */ if (chan->client_count) { __module_get(owner); chan->client_count++; return 0; } if (!try_module_get(owner)) return -ENODEV; if (!dma_device_get(chan->device)) { // calls kref_get_unless_zero() dma_chan_put() drops the ref unconditionally, so every fast-path get/put pair drops one extra device reference. The bug fires when two conditions hold together: a non-private provider has a persistent client holding chan->client_count > 0 and another client cycles dmaengine_get()/dmaengine_put(). When the kref hits zero, the subsequent dma_find_channel() returns NULL even though the provider module is still loaded. Fix this by dropping device->ref only on the last put, matching the single slow-path get. Fixes: 8ad342a86359 ("dmaengine: Add reference counting to dma_device struct") Reviewed-by: Frank Li Reviewed-by: Logan Gunthorpe Signed-off-by: Shivank Garg Link: https://patch.msgid.link/20260822-dmaengine-kref-fix-v5-2-d4a4ee47d927@amd.com Signed-off-by: Vinod Koul

dmaengine: add dma_device_get() helper

2026-09-09T12:21:44+00:00

Add dma_device_get() helper to match dma_device_put() to make code symmetric. It wraps open-coded kref_get_unless_zero() and asserts that dma_list_mutex is held, matching its put counterpart. No functional change intended. Suggested-by: Frank Li Reviewed-by: Logan Gunthorpe Signed-off-by: Shivank Garg Link: https://patch.msgid.link/20260822-dmaengine-kref-fix-v5-1-d4a4ee47d927@amd.com Signed-off-by: Vinod Koul

dmaengine: validate dev and name in dma_request_chan()

2026-07-17T12:26:45+00:00

dma_request_chan() assumes both @dev and @name are valid, but neither is checked before use. dev is dereferenced immediately via dev_fwnode(), which accesses dev->of_node or dev->fwnode without checking for NULL. Likewise, if name is NULL and the OF/ACPI lookup does not succeed, the legacy filter-map path eventually passes it to strcmp(), resulting in a NULL pointer dereference. These are caller bugs rather than normal lookup failures, so add a WARN_ON() at function entry to catch invalid arguments early during development instead of crashing later. No functional change for valid callers. Signed-off-by: bui duc phuc Reviewed-by: Frank Li Link: https://patch.msgid.link/20260716052758.23465-1-phucduc.bui@gmail.com Signed-off-by: Vinod Koul

dmaengine: Add safe API to combine configuration and preparation

2026-06-30T11:12:30+00:00

Introduce dmaengine_prep_config_single_safe() and dmaengine_prep_config_sg_safe() to provide a reentrant-safe way to combine slave configuration and transfer preparation. Drivers may implement the new device_prep_config_sg() callback to perform both steps atomically. If the callback is not provided, the helpers fall back to calling dmaengine_slave_config() followed by dmaengine_prep_slave_sg() under per-channel spinlock protection. Tested-by: Niklas Cassel Signed-off-by: Frank Li Link: https://patch.msgid.link/20260521-dma_prep_config-v7-2-1f73f4899883@nxp.com Signed-off-by: Vinod Koul

dmaengine: Fix possible use after free

2026-06-08T12:07:06+00:00

In dma_release_channel(), check chan->device->privatecnt after call dma_chan_put(). However, dma_chan_put() call dma_device_put() which could release the last reference of the device if the DMA provider is already gone and hence free it. Fixes it by moving dma_chan_put() after the check. Fixes: 0f571515c332 ("dmaengine: Add privatecnt to revert DMA_PRIVATE property") Signed-off-by: Nuno Sá Reviewed-by: Frank Li Link: https://patch.msgid.link/20260424-dma-dmac-handle-vunmap-v4-1-90f43412fdc0@analog.com Signed-off-by: Vinod Koul

dmaengine: Sort headers alphabetically

2026-02-26T15:30:01+00:00

For better maintenance sort headers alphabetically. Signed-off-by: Andy Shevchenko Reviewed-by: Dave Jiang Reviewed-by: Frank Li Link: https://patch.msgid.link/20260109173718.3605829-4-andriy.shevchenko@linux.intel.com Signed-off-by: Vinod Koul

dmaengine: Use device_match_of_node() helper

2026-02-26T15:30:01+00:00

Instead of open coding, use device_match_of_node() helper. Signed-off-by: Andy Shevchenko Reviewed-by: Dave Jiang Reviewed-by: Frank Li Link: https://patch.msgid.link/20260109173718.3605829-3-andriy.shevchenko@linux.intel.com Signed-off-by: Vinod Koul

dmaengine: Refactor devm_dma_request_chan() for readability

2026-02-26T15:30:01+00:00

Yes, while it's a bit longer in terms of LoCs, it's more readable when we use the usual patter to check for errors, and not for a success). This eliminates unneeded assignment and moves the needed one closer to its user which is better programming pattern because it allows avoiding potential errors in case the variable is getting reused. Also note that the same pattern have been used already in dmaenginem_async_device_register(). Signed-off-by: Andy Shevchenko Reviewed-by: Dave Jiang Reviewed-by: Frank Li Link: https://patch.msgid.link/20260109173718.3605829-2-andriy.shevchenko@linux.intel.com Signed-off-by: Vinod Koul