Re: [PATCH 2/4] speakup: Do not hold spk_mutex across catch_up()

[Hongyu Xie]

Hello,

Since my last reply I ran an automated A/B boot test of the series in
QEMU (TCG, q35, busybox initramfs) that reproduces the stall from the
report: speakup_apollo on ttyS1 whose backend never reads, so the tty
runs out of room and catch_up() keeps retrying with nothing draining
it.

Without the series, rmmod speakup_apollo never returned within a 50s
window. The hung task reports escalated from 10s to 102s, with the
stack pinned at __mutex_lock <- synth_remove and the speakup thread
stuck inside do_catch_up: rmmod dies on the mutex, before reaching
synth_release() at all.

With the series applied, rmmod returned in all six trials, covering
repeated load/speak/unload cycles, the spkout synth, switching synths
at load time, switching back through sysfs, a no-op unload, and a
stale-fd write. No oops. A write through a /dev/synth fd kept open
across the removal now returns -ENODEV.

One number to be upfront about: with the series, unloading a synth
whose tty is still wedged takes about 30s per round. That wait comes
from the tty layer's close timeout (tty_wait_until_sent called by
spk_ttyio_release); it is bounded and preexisting - the series does
not touch that path. The unpatched behavior never finishes at all, so
the unload moves from an unbounded hang to a bounded wait.

Hongyu