[RFC] spi: handling a stuck queue worker during controller unregister

[zhang san]

Hello,

We would appreciate guidance on the cleanup policy when the SPI queue
worker does not stop during controller unregister.

If spi_stop_queue() times out, spi_destroy_queue() may return without
destroying the worker. Our reading of the subsequent
spi_unregister_controller() cleanup path suggests that the controller
and child spi_device objects can be released while a stuck
__spi_pump_messages() operation still accesses them.

Using a synthetic SPI controller whose transfer_one() stalls beyond
the queue-stop timeout, we reproduced 80 KASAN use-after-free reports
on Linux v7.4-rc1 (6628e7d4c6b2). We explored three approaches:

A. Keep an additional reference to the controller while allowing
normal cleanup. This left 16 KASAN reports, involving released child
spi_device state.
B. Preserve the controller and child-device tree on queue teardown
failure. This removed the observed KASAN reports but leaves
substantial resources registered and allocated.
C. Preserve the child devices while continuing some controller-level
unregister operations. This is a design option that has not been
implemented or tested.

We do not propose approach B as a ready-to-merge fix: keeping the
entire registered tree can have unacceptable resource and visibility
consequences. Nor do we have evidence yet that approach C is correct.

Would it be preferable to ensure per-message ownership of the
controller and child device until the pump has definitely terminated,
or is there a safer failure policy already used elsewhere in the SPI
core?

We can provide the prototype diffs, KASAN traces, and test setup
privately. The experiments used a synthetic controller, so hardware
equivalence remains to be established.

If a patch is proposed, please CC me so I can run our KASAN reproducer
against that exact revision and offer a Tested-by tag after a
successful test. If the reported lifetime issue or a concrete design
suggestion informs a later fix, please feel free to reference this
thread in the commit message for attribution and review history.

This analysis originated from an AI-assisted audit and was reviewed
and tested by us.

Best regards
Yaohan Li