On 09/03/2022 09:23, Takashi Iwai wrote:
On Wed, 09 Mar 2022 10:02:13 +0100, Tvrtko Ursulin wrote:
On 09/03/2022 08:39, Kai Vehmanen wrote:
Hi,
On Wed, 9 Mar 2022, Tvrtko Ursulin wrote:
/* 60s timeout */Where does this 60s come from and why is the fix to work around DEFAULT_HUNG_TASK_TIMEOUT in a hacky way deemed okay? For instance would limiting the wait here to whatever the kconfig is set to be an option?
this was discussed in https://lists.freedesktop.org/archives/intel-gfx/2022-February/290821.html ... and that thread concluded it's cleaner to split the wait than try to figure out hung-task configuration from middle of audio driver.
The 60sec timeout comes from 2019 patch "ALSA: hda: Extend i915 component bind timeout" to fix an issue reported by Paul Menzel (cc'ed).
This patch keeps the timeout intact.
I did not spot discussion touching on the point I raised.
How about not fight the hung task detector but mark your wait context as "I really know what I'm doing - not stuck trust me".
The question is how often this problem hits. Basically it's a very corner case, and I even think we may leave as is; that's a matter of configuration, and lowering such a bar should expect some side-effect. OTOH, if the problem happens in many cases, it's beneficial to fix in the core part, indeed.
Yes argument you raise can be made I agree.
Maybe using wait_for_completion_killable_timeout would do it since snd_hdac_i915_init is allowed to fail with an error already?
It makes it killable -- which is a complete behavior change.
Complete behaviour change how? Isn't this something ran on probe so likelihood of anyone sending SIGKILL to the modprobe process is only the init process? And in that case what is the fundamental difference in init giving up before the internal 60s in HDA driver does? I don't see a difference. Either party decided to abort the wait and code can just unwind and propagate the different error codes.
Regards,
Tvrtko