Re: [PATCH v2 0/4] spi: Fix DMA mapping ownership on partial map failure

[Andy Shevchenko <andriy.shevchenko@linux.intel.com>]

On Fri, Aug 14, 2026 at 11:14:14AM +0800, Honghui Jiang wrote:
> 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.

Nice series!
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
with a caveat that there is one stray change in the last patch.
Assumed that in v3 it will be dropped.

-- 
With Best Regards,
Andy Shevchenko