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 EEB67C433F5 for ; Wed, 9 Mar 2022 08:55:27 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 526B710E266; Wed, 9 Mar 2022 08:55:27 +0000 (UTC) Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by gabe.freedesktop.org (Postfix) with ESMTPS id 9BF2D10E300 for ; Wed, 9 Mar 2022 08:55:25 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 4A844210EF; Wed, 9 Mar 2022 08:55:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1646816124; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=cpm2OEfKKEgD+WpLsKYGIHOSTyipa6Nz2Y9FJUBjGcI=; b=ZJPHo+6N+hYcML7ViZi5r/2b6g+Td66lu6lCSATR2UpHGjpN9KiU2cVtbQ/MIuYHHHSjso hVu1k2IR+QhE0U/Du3chCKLuC9wqeE03FeuxHCCBnS94KdW6GkAIMV7pNIhnauI+2xUS5f WMvARyh4Xo+cIgU5hP9RzQIrHeXEbWs= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1646816124; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=cpm2OEfKKEgD+WpLsKYGIHOSTyipa6Nz2Y9FJUBjGcI=; b=FdVkCjGJv0vvExrkIJ9cVHkclDa1nRqClqRnGAjWkxNpIHz1NC91uj/GZwFEUmleL2WAk8 jsuOf2TdutAF7pAw== Received: from alsa1.suse.de (alsa1.suse.de [10.160.4.42]) by relay2.suse.de (Postfix) with ESMTP id 38D1BA3B81; Wed, 9 Mar 2022 08:55:23 +0000 (UTC) Date: Wed, 09 Mar 2022 09:55:23 +0100 Message-ID: From: Takashi Iwai To: Tvrtko Ursulin In-Reply-To: References: <20220308172759.920551-1-kai.vehmanen@linux.intel.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/25.3 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII 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, Lucas De Marchi , intel-gfx@lists.freedesktop.org, amadeuszx.slawinski@linux.intel.com Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On Wed, 09 Mar 2022 09:36:54 +0100, Tvrtko Ursulin wrote: > > > On 08/03/2022 17:27, Kai Vehmanen wrote: > > If kernel is built with hung task detection enabled and > > CONFIG_DEFAULT_HUNG_TASK_TIMEOUT set to less than 60 seconds, > > snd_hdac_i915_init() will trigger the hung task timeout in case i915 is > > not available and taint the kernel. > > > > Split the 60sec wait into a loop of smaller waits to avoid this. > > > > Reviewed-by: Lucas De Marchi > > Co-developed-by: Ramalingam C > > Signed-off-by: Ramalingam C > > Signed-off-by: Kai Vehmanen > > --- > > sound/hda/hdac_i915.c | 10 ++++++---- > > 1 file changed, 6 insertions(+), 4 deletions(-) > > > > Changes V1->V2: > > - address local variable naming issue raised by Amadeusz > > and use Takashi's proposal > > > > diff --git a/sound/hda/hdac_i915.c b/sound/hda/hdac_i915.c > > index 454474ac5716..aa48bed7baf7 100644 > > --- a/sound/hda/hdac_i915.c > > +++ b/sound/hda/hdac_i915.c > > @@ -143,7 +143,7 @@ static bool i915_gfx_present(void) > > int snd_hdac_i915_init(struct hdac_bus *bus) > > { > > struct drm_audio_component *acomp; > > - int err; > > + int err, i; > > if (!i915_gfx_present()) > > return -ENODEV; > > @@ -159,9 +159,11 @@ int snd_hdac_i915_init(struct hdac_bus *bus) > > if (!acomp->ops) { > > if (!IS_ENABLED(CONFIG_MODULES) || > > !request_module("i915")) { > > - /* 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? The 60s timeout comes from the fact that the binding with i915 *might* be mandatory for HD-audio driver on some platforms, while the binding couldn't be achieved depending on the dynamic configuration change or any other reasons, so we don't want to block forver. And, basically the hung check is false-positive, and if there is a better way to mark to skip the hung check, we'd take it. But currently this seems to be the easiest workaround for avoiding the false-positive checks. > For instance > would limiting the wait here to whatever the kconfig is set to be an > option? No, the hunk task timeout can be changed dynamically via procfs, hence the fixed Kconfig won't help at all. Takashi