>> We could do cancel_work_sync() as a recovery, but that call blocks until the >> running async task is flushed, which might never happen. So doing a panic() >> is pretty much the only option for recovering. > > Well, its usefulness is quite limited, then. That said I'm still not > convinced > that this actually is the case.
It does block in my environment, AFAICS. Looking a bit further in the code, it looks like dpm_suspend() does an async_synchronize_full() which would wait for all async tasks to complete. This is a show-stopper because (under the circumstances) the assumption that every async suspend routine eventually completes doesn't hold. We could possibly select which async tasks to wait for, but this would add unnecessary complexity to a feature targeted for debugging. It seems that this approach - although sounding reasonable - needs to wait until we have a mechanism to cancel an async task. Regards, Zoran -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
