spi: Fix DMA mapping ownership on partial map failure

Honghui Jiang <jiang_hh2019@163.com> says:

A partial DMA mapping failure can leave per-transfer mapping flags set
while cur_{tx,rx}_dma_dev are NULL or still refer to the devices used
for an earlier message. The subsequent cleanup may then unmap a
transfer with a NULL or stale device.

Before commit e289df82344f ("spi: Rework per message DMA mapped flag to
be per transfer"), partial-failure handling was already incomplete, but
__spi_unmap_msg() was gated by cur_msg_mapped, which was set only after
the whole message mapped successfully. Earlier mappings could leak, but
cleanup could not unmap them with an unpublished device. The
per-transfer conversion removed that gate: mapping flags can now remain
set while cur_{tx,rx}_dma_dev are still unpublished, turning the leak
into a NULL- or stale-device unmap regression.

Patch 1 publishes the mapping devices before the loop and unwinds every
failure through __spi_unmap_msg(). It keeps the forward declaration so
it is independently buildable and straightforward to backport. Patch 2
then removes the declaration by moving __spi_unmap_msg() above
__spi_map_msg(). Patch 3 clears the current DMA device pointers once the
message has been unmapped, while leaving them intact during partial-map
unwind and DMA-to-PIO fallback. Patch 4 adds the DMA mapping KUnit suite
as a separate translation unit.

Only patch 1 is a stable candidate; patches 2 through 4 are follow-up
cleanup and test changes for mainline.

Testing:

- Patch 1 builds independently with the x86_64 reproducer configuration.
- The spi_dma KUnit suite passes all four cases on x86_64 and UML.
  Moving the DMA device assignments back after the mapping loop makes
  both failure-path cases fail.
- The default and all-tests KUnit configurations both select the suite.
- All four reproducer cases complete without an oops when run as the
  first message, and map/unmap counts are balanced after a successful
  first message.
- After message cleanup, cur_{tx,rx}_dma_dev are NULL.

v1: https://lore.kernel.org/r/20260805151456.756579-1-jiang_hh2019@163.com

Link: https://patch.msgid.link/20260814031419.43378-1-jiang_hh2019@163.com

0 files changed, 0 insertions, 0 deletions