kernel/linux.git/drivers/dma/dmatest.c, branch v5.15.208

dmaengine: Revert "dmaengine: dmatest: Fix dmatest waiting less when interrupted"

2025-05-22T12:08:24+00:00

commit df180e65305f8c1e020d54bfc2132349fd693de1 upstream. Several issues with this change: * The analysis is flawed and it's unclear what problem is being fixed. There is no difference between wait_event_freezable_timeout() and wait_event_timeout() with respect to device interrupts. And of course "the interrupt notifying the finish of an operation happens during wait_event_freezable_timeout()" -- that's how it's supposed to work. * The link at the "Closes:" tag appears to be an unrelated use-after-free in idxd. * It introduces a regression: dmatest threads are meant to be freezable and this change breaks that. See discussion here: https://lore.kernel.org/dmaengine/878qpa13fe.fsf@AUSNATLYNCH.amd.com/ Fixes: e87ca16e9911 ("dmaengine: dmatest: Fix dmatest waiting less when interrupted") Signed-off-by: Nathan Lynch Link: https://lore.kernel.org/r/20250403-dmaengine-dmatest-revert-waiting-less-v1-1-8227c5a3d7c8@amd.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman

dmaengine: dmatest: Fix dmatest waiting less when interrupted

2025-05-02T05:44:35+00:00

[ Upstream commit e87ca16e99118ab4e130a41bdf12abbf6a87656c ] Change the "wait for operation finish" logic to take interrupts into account. When using dmatest with idxd DMA engine, it's possible that during longer tests, the interrupt notifying the finish of an operation happens during wait_event_freezable_timeout(), which causes dmatest to cleanup all the resources, some of which might still be in use. This fix ensures that the wait logic correctly handles interrupts, preventing premature cleanup of resources. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-lkp/202502171134.8c403348-lkp@intel.com Signed-off-by: Vinicius Costa Gomes Reviewed-by: Dave Jiang Link: https://lore.kernel.org/r/20250305230007.590178-1-vinicius.gomes@intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin

dmaengine: dmatest: Use dmaengine_get_dma_device

2020-12-11T15:50:08+00:00

By using the dmaengine_get_dma_device() to get the device for dma_api use, the dmatest can support per channel coherency if it is supported by the DMA controller. Signed-off-by: Peter Ujfalusi Link: https://lore.kernel.org/r/20201208090440.31792-11-peter.ujfalusi@ti.com Signed-off-by: Vinod Koul

dmaengine: dmatest: Return boolean result directly in filter()

2020-09-22T14:48:41+00:00

There is no need to have a conditional for boolean expression when function returns bool. Drop unnecessary code and return boolean result directly. While at it, drop unneeded casting from void *. Cc: Vladimir Murzin Signed-off-by: Andy Shevchenko Tested-by: Peter Ujfalusi Link: https://lore.kernel.org/r/20200922115847.30100-3-andriy.shevchenko@linux.intel.com Signed-off-by: Vinod Koul

dmaengine: dmatest: Check list for emptiness before access its last entry

2020-09-22T14:48:41+00:00

After writing a garbage to the channel we get an Oops in dmatest_chan_set() due to access to last entry in the empty list. [ 212.670672] BUG: unable to handle page fault for address: fffffff000000020 [ 212.677562] #PF: supervisor read access in kernel mode [ 212.682702] #PF: error_code(0x0000) - not-present page ... [ 212.710074] RIP: 0010:dmatest_chan_set+0x149/0x2d0 [dmatest] [ 212.715739] Code: e8 cc f9 ff ff 48 8b 1d 0d 55 00 00 48 83 7b 10 00 0f 84 63 01 00 00 48 c7 c7 d0 65 4d c0 e8 ee 4a f5 e1 48 89 c6 48 8b 43 10 <48> 8b 40 20 48 8b 78 58 48 85 ff 0f 84 f5 00 00 00 e8 b1 41 f5 e1 Fix this by checking list for emptiness before accessing its last entry. Fixes: d53513d5dc28 ("dmaengine: dmatest: Add support for multi channel testing") Cc: Vladimir Murzin Signed-off-by: Andy Shevchenko Tested-by: Peter Ujfalusi Link: https://lore.kernel.org/r/20200922115847.30100-2-andriy.shevchenko@linux.intel.com Signed-off-by: Vinod Koul

Merge branch 'fixes' into next

2020-09-22T14:48:32+00:00

dmaengine: dmatest: Prevent to run on misconfigured channel

2020-09-22T14:48:05+00:00

Andy reported that commit 6b41030fdc79 ("dmaengine: dmatest: Restore default for channel") broke his scripts for the case where "busy" channel is used for configuration with expectation that run command would do nothing. Instead, behavior was (unintentionally) changed to treat such case as under-configuration and progress with defaults, i.e. run command would start a test with default setting for channel (which would use all channels). Restore original behavior with tracking status of channel setter so we can distinguish between misconfigured and under-configured cases in run command and act accordingly. Fixes: 6b41030fdc79 ("dmaengine: dmatest: Restore default for channel") Reported-by: Andy Shevchenko Tested-by: Andy Shevchenko Signed-off-by: Vladimir Murzin Tested-by: Peter Ujfalusi Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20200922115847.30100-1-andriy.shevchenko@linux.intel.com Signed-off-by: Vinod Koul

dmaengine: dmatest: Print error codes as signed value

2020-09-11T12:14:28+00:00

When we got an error from DMA mapping API we convert a negative value to unsigned long type and hence make user confused: result #1: 'src mapping error' with src_off=0x19a72 dst_off=0xea len=0xccf4 (18446744073709551604) Change this to print error codes as signed values. Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20200907101306.61824-1-andriy.shevchenko@linux.intel.com Signed-off-by: Vinod Koul

Merge branch 'for-linus' into fixes

2020-08-05T13:32:07+00:00

Signed-off-by: Vinod Koul Conflicts: drivers/dma/idxd/sysfs.c

dmaengine: dmatest: stop completed threads when running without set channel

2020-07-06T05:12:17+00:00

The completed threads were not cleared and consequent run would result threads accumulating: echo 800000 > /sys/module/dmatest/parameters/test_buf_size echo 2000 > /sys/module/dmatest/parameters/timeout echo 50 > /sys/module/dmatest/parameters/iterations echo 1 > /sys/module/dmatest/parameters/max_channels echo "" > /sys/module/dmatest/parameters/channel [ 237.507265] dmatest: Added 1 threads using dma1chan2 echo 1 > /sys/module/dmatest/parameters/run [ 244.713360] dmatest: Started 1 threads using dma1chan2 [ 246.117680] dmatest: dma1chan2-copy0: summary 50 tests, 0 failures 2437.47 iops 977623 KB/s (0) echo 1 > /sys/module/dmatest/parameters/run [ 292.381471] dmatest: No channels configured, continue with any [ 292.389307] dmatest: Added 1 threads using dma1chan3 [ 292.394302] dmatest: Started 1 threads using dma1chan2 [ 292.399454] dmatest: Started 1 threads using dma1chan3 [ 293.800835] dmatest: dma1chan3-copy0: summary 50 tests, 0 failures 2624.53 iops 975014 KB/s (0) echo 1 > /sys/module/dmatest/parameters/run [ 307.301429] dmatest: No channels configured, continue with any [ 307.309212] dmatest: Added 1 threads using dma1chan4 [ 307.314197] dmatest: Started 1 threads using dma1chan2 [ 307.319343] dmatest: Started 1 threads using dma1chan3 [ 307.324492] dmatest: Started 1 threads using dma1chan4 [ 308.730773] dmatest: dma1chan4-copy0: summary 50 tests, 0 failures 2390.28 iops 965436 KB/s (0) Fixes: 6b41030fdc79 ("dmaengine: dmatest: Restore default for channel") Reported-by: Grygorii Strashko Signed-off-by: Peter Ujfalusi Link: https://lore.kernel.org/r/20200701101225.8607-1-peter.ujfalusi@ti.com Signed-off-by: Vinod Koul