Now suppose that the callout runs right after the pcm_unregister() call. Will it do anything unsafe? That is, does it assume that pcm_unregister has not yet been called?

dummy_chan_io() assumes that the channels are not freed, so if it somehow runs after pcm_unregister(), we'll get a user-after-free in the channel loop. However, pcm_unregister() calls chn_abort() (and callout_stop() as a result) on all channels before freeing them (so starting the callout from within pcm_unregister() shouldn't be a concern), and because we've also cleared SD_F_REGISTERED at this point, I don't see how we could trigger the channels with PCMTRIG_START (i.e. call chn_start()) after pcm_unregister() in order to re-schedule the callout.

Whereas, if pcm_unregister() is called after callout_drain(), we do indeed run the risk of re-scheduling the callout, since we might end up calling chn_start() in the time window between callout_drain() and pcm_unregister(). IIRC that's a scenario I managed to reproduce with stress2, for example.

Am I missing something?

pcm_unregister() should prevent the channels from starting again. But I'm trying to wrap my head around whether chn_abort() executing callout_stop() in dummy_chan_trigger() is actually guaranteed to stop the rescheduling of dummy_chan_io(). We don't check the return value of callout_stop(), and dummy_chan_io() might reschedule itself when it is running at the same time?

Also, shouldn't a callout_drain() be enough here? Why the additional callout_stop()?