__spi_map_msg() can fail after mapping only part of a message.  The
normal cleanup path may then act on stale mapped flags using a NULL or
stale DMA device, causing a NULL dereference or an extra unmap.

The core DMA mapping path is used by 28 in-tree SPI controllers.  The
bug remains reachable until a controller completes its first DMA-mapped
message, since cur_{tx,rx}_dma_dev are only set on success.  can_dma()
length checks may postpone that point well beyond probe.  A two-transfer
message with a mapped command followed by an unmappable static payload
reproduces the failure without memory pressure.

Patch 1 publishes the mapping devices before mapping starts and uses a
common unwind path for all failures.  Patch 2 adds KUnit coverage for
partial TX and RX mapping failures, successful map/unmap, and messages
which require no mapping.

Tested on v7.2-rc6 under x86_64 QEMU with KASAN.  All three cases that
previously oopsed complete cleanly after the fix, and the RX-only case
no longer issues an empty unmap.  DMA map/unmap counts changed from
3/4, 2/3 and 5/6 to 3/3, 2/2 and 5/5.

Two of the four KUnit cases fail without patch 1; all four pass with it.
Patch 1 also builds independently with x86_64_defconfig plus SPI.

Honghui Jiang (2):
  spi: Fix DMA mapping ownership on partial map failure
  spi: Add KUnit coverage for DMA mapping error paths

 drivers/spi/.kunitconfig      |   4 +
 drivers/spi/Kconfig           |  11 ++
 drivers/spi/spi.c             |  37 +++--
 drivers/spi/tests/spi_kunit.c | 301 ++++++++++++++++++++++++++++++++++
 4 files changed, 338 insertions(+), 15 deletions(-)
 create mode 100644 drivers/spi/.kunitconfig
 create mode 100644 drivers/spi/tests/spi_kunit.c


base-commit: 075b74841bd0065a3bda3440873c747938e69b68
-- 
2.43.0