From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 97BA3C433EF for ; Wed, 9 Mar 2022 09:48:58 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 01BF410E2FD; Wed, 9 Mar 2022 09:48:58 +0000 (UTC) Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by gabe.freedesktop.org (Postfix) with ESMTPS id F1D5910E328 for ; Wed, 9 Mar 2022 09:48:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1646819336; x=1678355336; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=cFfI6vG30MN8c6f0ChAcUW0bKNeCWZvgFlXcJRGc81k=; b=npO5+0CXCivrc22ylPhhSCZ0vUmHh3IFG7JxDkVRpv0R12xmp9xHIw2c vUVsmQpB/16pV2IALZT8XJBH7/uURCTgjBxWt8u8Bop1MB7LVj4llP1Ss gSO6R33TpRmqP1Ou/vva3y8EPZk1kCOsh1oXtW6PaBc7lAK/UMyDSESx8 z2BxeL6FNbRLutubs6KH7Ut9tIV1F0FGTWD0e8irWDPFHILEY5NXVYic7 rsNUpoRirsmDLJtZFTej/qq6avqgO2gpKaCbRHMQBIsIF8bufN4/k+NWu LDwqe/fbq8/sKe1XE7PWQ4hecRYeS2bK6CTMYBY5URITeurX6ZoLmwiIm A==; X-IronPort-AV: E=McAfee;i="6200,9189,10280"; a="341364356" X-IronPort-AV: E=Sophos;i="5.90,167,1643702400"; d="scan'208";a="341364356" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Mar 2022 01:48:53 -0800 X-IronPort-AV: E=Sophos;i="5.90,167,1643702400"; d="scan'208";a="642092100" Received: from hedwards-mobl1.ger.corp.intel.com (HELO [10.213.198.86]) ([10.213.198.86]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Mar 2022 01:48:52 -0800 Message-ID: Date: Wed, 9 Mar 2022 09:48:49 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Content-Language: en-US To: Takashi Iwai References: <20220308172759.920551-1-kai.vehmanen@linux.intel.com> <9dabb68b-f2af-ae97-0fb2-869367c496bf@linux.intel.com> From: Tvrtko Ursulin Organization: Intel Corporation UK Plc In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Intel-gfx] [PATCH v2] ALSA: hda/i915 - avoid hung task timeout in i915 wait X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: alsa-devel@alsa-project.org, Paul Menzel , intel-gfx@lists.freedesktop.org, Lucas De Marchi , amadeuszx.slawinski@linux.intel.com Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" 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