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

Several issues with this change:

* The analysis is flawed and it's unclear what problem is being
fixed. There is

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

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/[email protected]/

Fixes: e87ca16e9911 ("dmaengine: dmatest: Fix dmatest waiting less when interrupted")
Signed-off-by: Nathan Lynch <[email protected]>
Link: https://lore.kernel.org/r/20250403-dmaengine-dmatest-revert-waiting-less-v1-1-8227c5a3d7c8@amd.com
Signed-off-by: Vinod Koul <[email protected]>

show more ...

dmaengine: dmatest: Fix dmatest waiting less when interrupted

Change the "wait for operation finish" logic to take interrupts into
account.

When using dmatest with idxd DMA engine, it's possible th

dmaengine: dmatest: Fix dmatest waiting less when interrupted

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 <[email protected]>
Closes: https://lore.kernel.org/oe-lkp/[email protected]
Signed-off-by: Vinicius Costa Gomes <[email protected]>
Reviewed-by: Dave Jiang <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Vinod Koul <[email protected]>

show more ...

dmaengine: dmatest: Explicitly cast divisor to u32

As the comment explains, the while loop ensures that runtime fits into
32 bits. Since do_div() casts the divisor to u32 anyway, explicitly cast
run

dmaengine: dmatest: Explicitly cast divisor to u32

As the comment explains, the while loop ensures that runtime fits into
32 bits. Since do_div() casts the divisor to u32 anyway, explicitly cast
runtime to u32 to remove the following Coccinelle/coccicheck warning
reported by do_div.cocci:

WARNING: do_div() does a 64-by-32 division, please consider using div64_s64 instead

Signed-off-by: Thorsten Blum <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Vinod Koul <[email protected]>

show more ...

dmaengine: add missing MODULE_DESCRIPTION() macros

make allmodconfig && make W=1 C=1 reports:
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/dma/idxd/idxd.o
WARNING: modpost: missing MODU

dmaengine: add missing MODULE_DESCRIPTION() macros

make allmodconfig && make W=1 C=1 reports:
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/dma/idxd/idxd.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/dma/ti/omap-dma.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/dma/dmatest.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/dma/ioat/ioatdma.o

Add the missing invocations of the MODULE_DESCRIPTION() macro.

Acked-by: Dave Jiang <[email protected]>
Signed-off-by: Jeff Johnson <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Vinod Koul <[email protected]>

show more ...

dmaengine: dmatest: prevent using swiotlb buffer with nobounce parameter

Source and destination data buffers are allocated with GPF_KERNEL flag.
It means that, if the DDR is more than 2GB, buffers c

dmaengine: dmatest: prevent using swiotlb buffer with nobounce parameter

Source and destination data buffers are allocated with GPF_KERNEL flag.
It means that, if the DDR is more than 2GB, buffers can be allocated above
the 32-bit addressable space. In this case, and if the dma controller is
only 32-bit compatible, swiotlb bounce buffer, located in the 32-bit
addressable space, is used and introduces a memcpy.

To prevent this extra memcpy, due to swiotlb bounce buffer use because
source or destination data buffer is allocated above the 32-bit addressable
space, force source and destination data buffers allocation with GPF_DMA
instead, when nobounce parameter is true.

Signed-off-by: Amelie Delaunay <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Vinod Koul <[email protected]>

show more ...

treewide: use get_random_bytes() when possible

The prandom_bytes() function has been a deprecated inline wrapper around
get_random_bytes() for several releases now, and compiles down to the
exact sa

treewide: use get_random_bytes() when possible

The prandom_bytes() function has been a deprecated inline wrapper around
get_random_bytes() for several releases now, and compiles down to the
exact same code. Replace the deprecated wrapper with a direct call to
the real function. This was done as a basic find and replace.

Reviewed-by: Greg Kroah-Hartman <[email protected]>
Reviewed-by: Kees Cook <[email protected]>
Reviewed-by: Yury Norov <[email protected]>
Reviewed-by: Christophe Leroy <[email protected]> # powerpc
Acked-by: Jakub Kicinski <[email protected]>
Signed-off-by: Jason A. Donenfeld <[email protected]>

show more ...

dmaengine: dmatest: use strscpy to replace strlcpy

The strlcpy should not be used because it doesn't limit the source
length. Preferred is strscpy.

Signed-off-by: XueBing Chen <[email protected]>

dmaengine: dmatest: use strscpy to replace strlcpy

The strlcpy should not be used because it doesn't limit the source
length. Preferred is strscpy.

Signed-off-by: XueBing Chen <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Vinod Koul <[email protected]>

show more ...

dmaengine: dmatest: Replace symbolic permissions by octal permissions

Octal permissions are easier to read.

Signed-off-by: Geert Uytterhoeven <[email protected]>
Link: https://lore.kernel.org

dmaengine: dmatest: Replace symbolic permissions by octal permissions

Octal permissions are easier to read.

Signed-off-by: Geert Uytterhoeven <[email protected]>
Link: https://lore.kernel.org/r/a745b883288f95e999b71fac677bbc2daa13c22d.1654702928.git.geert+renesas@glider.be
Signed-off-by: Vinod Koul <[email protected]>

show more ...

dmaengine: dmatest: Remove spaces before tabs

Scripts/checkpath.pl says "please, no space before tabs".

Signed-off-by: Geert Uytterhoeven <[email protected]>
Link: https://lore.kernel.org/r/d

dmaengine: dmatest: Remove spaces before tabs

Scripts/checkpath.pl says "please, no space before tabs".

Signed-off-by: Geert Uytterhoeven <[email protected]>
Link: https://lore.kernel.org/r/d863916120d043e3f9dd2f2670238c34f68f7d5f.1654702886.git.geert+renesas@glider.be
Signed-off-by: Vinod Koul <[email protected]>

show more ...

dmaengine: Revert "dmaengine: add verification of DMA_INTERRUPT capability for dmatest"

This reverts commit a8facc7b9885 ("dmaengine: add verification of
DMA_INTERRUPT capability for dmatest") as it

dmaengine: Revert "dmaengine: add verification of DMA_INTERRUPT capability for dmatest"

This reverts commit a8facc7b9885 ("dmaengine: add verification of
DMA_INTERRUPT capability for dmatest") as it causes regression due to
the fact that DMA_INTERRUPT in linked to dma_prep_interrupt() so
checking that is incorrect here

Signed-off-by: Vinod Koul <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Vinod Koul <[email protected]>

show more ...

dmaengine: add verification of DMA_INTERRUPT capability for dmatest

Looks like I forgot to add DMA_INTERRUPT cap setting to the idxd driver and
dmatest is still working regardless of this mistake. A

dmaengine: add verification of DMA_INTERRUPT capability for dmatest

Looks like I forgot to add DMA_INTERRUPT cap setting to the idxd driver and
dmatest is still working regardless of this mistake. Add an explicit check
of DMA_INTERRUPT capability for dmatest to make sure the DMA device being used
actually supports interrupt before the test is launched and also that the
driver is programmed correctly.

Signed-off-by: Dave Jiang <[email protected]>
Link: https://lore.kernel.org/r/164978679251.2361020.5856734256126725993.stgit@djiang5-desk3.ch.intel.com
Signed-off-by: Vinod Koul <[email protected]>

show more ...

dmaengine: dmatest: Use dmaengine_get_dma_device

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 DM

dmaengine: dmatest: Use dmaengine_get_dma_device

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 <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Vinod Koul <[email protected]>

show more ...

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

There is no need to have a conditional for boolean expression when
function returns bool. Drop unnecessary code and return boolean
resu

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

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 <[email protected]>
Signed-off-by: Andy Shevchenko <[email protected]>
Tested-by: Peter Ujfalusi <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Vinod Koul <[email protected]>

show more ...

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

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.

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

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 <[email protected]>
Signed-off-by: Andy Shevchenko <[email protected]>
Tested-by: Peter Ujfalusi <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Vinod Koul <[email protected]>

show more ...

dmaengine: dmatest: Prevent to run on misconfigured channel

Andy reported that commit 6b41030fdc79 ("dmaengine: dmatest:
Restore default for channel") broke his scripts for the case
where "busy" cha

dmaengine: dmatest: Prevent to run on misconfigured channel

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 <[email protected]>
Tested-by: Andy Shevchenko <[email protected]>
Signed-off-by: Vladimir Murzin <[email protected]>
Tested-by: Peter Ujfalusi <[email protected]>
Signed-off-by: Andy Shevchenko <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Vinod Koul <[email protected]>

show more ...

dmaengine: dmatest: Print error codes as signed value

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 map

dmaengine: dmatest: Print error codes as signed value

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 <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Vinod Koul <[email protected]>

show more ...

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

The completed threads were not cleared and consequent run would result
threads accumulating:

echo 800000 > /sys/module/dm

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

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 <[email protected]>
Signed-off-by: Peter Ujfalusi <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Vinod Koul <[email protected]>

show more ...

dmaengine: cookie bypass for out of order completion

The cookie tracking in dmaengine expects all submissions completed in
order. Some DMA devices like Intel DSA can complete submissions out of
orde

dmaengine: cookie bypass for out of order completion

The cookie tracking in dmaengine expects all submissions completed in
order. Some DMA devices like Intel DSA can complete submissions out of
order, especially if configured with a work queue sharing multiple DMA
engines. Add a status DMA_OUT_OF_ORDER that tx_status can be returned for
those DMA devices. The user should use callbacks to track the completion
rather than the DMA cookie. This would address the issue of dmatest
complaining that descriptors are "busy" when the cookie count goes
backwards due to out of order completion. Add DMA_COMPLETION_NO_ORDER
DMA capability to allow the driver to flag the device's ability to complete
operations out of order.

Reported-by: Swathi Kovvuri <[email protected]>
Signed-off-by: Dave Jiang <[email protected]>
Tested-by: Swathi Kovvuri <[email protected]>
Link: https://lore.kernel.org/r/158939557151.20335.12404113976045569870.stgit@djiang5-desk3.ch.intel.com
Signed-off-by: Vinod Koul <[email protected]>

show more ...

dmaengine: dmatest: Restore default for channel

In case of dmatest is built-in and no channel was configured test
doesn't run with:

dmatest: Could not start test, no channels configured

Even thoug

dmaengine: dmatest: Restore default for channel

In case of dmatest is built-in and no channel was configured test
doesn't run with:

dmatest: Could not start test, no channels configured

Even though description to "channel" parameter claims that default is
any.

Add default channel back as it used to be rather than reject test with
no channel configuration.

Fixes: d53513d5dc285d9a95a534fc41c5c08af6b60eac ("dmaengine: dmatest: Add support for multi channel testing)
Reported-by: Dijil Mohan <[email protected]>
Signed-off-by: Vladimir Murzin <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Vinod Koul <[email protected]>

show more ...

dmaengine: dmatest: Fix process hang when reading 'wait' parameter

If we do

% echo 1 > /sys/module/dmatest/parameters/run
[ 115.851124] dmatest: Could not start test, no channels configured

dmaengine: dmatest: Fix process hang when reading 'wait' parameter

If we do

% echo 1 > /sys/module/dmatest/parameters/run
[ 115.851124] dmatest: Could not start test, no channels configured

% echo dma8chan7 > /sys/module/dmatest/parameters/channel
[ 127.563872] dmatest: Added 1 threads using dma8chan7

% cat /sys/module/dmatest/parameters/wait
... !!! HANG !!! ...

The culprit is the commit 6138f967bccc

("dmaengine: dmatest: Use fixed point div to calculate iops")

which makes threads not to run, but pending and being kicked off by writing
to the 'run' node. However, it forgot to consider 'wait' routine to avoid
above mentioned case.

In order to fix this, check for really running threads, i.e. with pending
and done flags unset.

It's pity the culprit commit hadn't updated documentation and tested all
possible scenarios.

Fixes: 6138f967bccc ("dmaengine: dmatest: Use fixed point div to calculate iops")
Cc: Seraj Alijan <[email protected]>
Signed-off-by: Andy Shevchenko <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Vinod Koul <[email protected]>

show more ...

dmaengine: dmatest: Describe members of struct dmatest_info

Kernel documentation validator complains that not all members of
struct dmatest_info are being described. Describe them all.

Signed-off-b

dmaengine: dmatest: Describe members of struct dmatest_info

Kernel documentation validator complains that not all members of
struct dmatest_info are being described. Describe them all.

Signed-off-by: Andy Shevchenko <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Vinod Koul <[email protected]>

show more ...

dmaengine: dmatest: Describe members of struct dmatest_params

Kernel documentation validator complains that not all members of
struct dmatest_params are being described. Describe them all.

Signed-o

dmaengine: dmatest: Describe members of struct dmatest_params

Kernel documentation validator complains that not all members of
struct dmatest_params are being described. Describe them all.

Signed-off-by: Andy Shevchenko <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Vinod Koul <[email protected]>

show more ...

dmaengine: dmatest: Allow negative timeout value to specify infinite wait

The dmatest module parameter 'timeout' is documented as accepting a -1 to mean
"infinite timeout". However, an infinite time

dmaengine: dmatest: Allow negative timeout value to specify infinite wait

The dmatest module parameter 'timeout' is documented as accepting a -1 to mean
"infinite timeout". However, an infinite timeout is not advised, nor possible
since the module parameter is an unsigned int, which won't accept a negative
value. Change the parameter type to be signed integer.

Cc: Gary Hook <[email protected]>
Signed-off-by: Andy Shevchenko <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Vinod Koul <[email protected]>

show more ...

Revert "dmaengine: dmatest: timeout value of -1 should specify infinite wait"

This reverts commit ed04b7c57c3383ed4573f1d1d1dbdc1108ba0bed.

While it gives a good description what happens, the appro

Revert "dmaengine: dmatest: timeout value of -1 should specify infinite wait"

This reverts commit ed04b7c57c3383ed4573f1d1d1dbdc1108ba0bed.

While it gives a good description what happens, the approach seems too
confusing. Let's fix it in the following patch.

Cc: Gary Hook <[email protected]>
Signed-off-by: Andy Shevchenko <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Vinod Koul <[email protected]>

show more ...

dmaengine: dmatest: Fix iteration non-stop logic

Under some circumstances, i.e. when test is still running and about to
time out and user runs, for example,

grep -H . /sys/module/dmatest/parameter

dmaengine: dmatest: Fix iteration non-stop logic

Under some circumstances, i.e. when test is still running and about to
time out and user runs, for example,

grep -H . /sys/module/dmatest/parameters/*

the iterations parameter is not respected and test is going on and on until
user gives

echo 0 > /sys/module/dmatest/parameters/run

This is not what expected.

The history of this bug is interesting. I though that the commit
2d88ce76eb98 ("dmatest: add a 'wait' parameter")
is a culprit, but looking closer to the code I think it simple revealed the
broken logic from the day one, i.e. in the commit
0a2ff57d6fba ("dmaengine: dmatest: add a maximum number of test iterations")
which adds iterations parameter.

So, to the point, the conditional of checking the thread to be stopped being
first part of conjunction logic prevents to check iterations. Thus, we have to
always check both conditions to be able to stop after given iterations.

Since it wasn't visible before second commit appeared, I add a respective
Fixes tag.

Fixes: 2d88ce76eb98 ("dmatest: add a 'wait' parameter")
Cc: Dan Williams <[email protected]>
Cc: Nicolas Ferre <[email protected]>
Signed-off-by: Andy Shevchenko <[email protected]>
Acked-by: Nicolas Ferre <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Vinod Koul <[email protected]>

show more ...