From nobody Wed Apr 15 16:36:15 2026 Received: from mail-pl1-f181.google.com (mail-pl1-f181.google.com [209.85.214.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EEC28C2FF for ; Wed, 4 Mar 2026 03:15:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.181 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772594118; cv=none; b=Cs0wDYekrxKfFmarXnOegfi3+SC/HYaQBvfGkjfE4f0Bu8bevWUL3PeSeAO5+QFxCh+KVG7UD2DGFuLBnrDBtH425YNxPsuuXIvb5haP8Wk4SwRYQcAu7VG2EQebJUR5o446h0xkvuLpvF/7L+oyDqZ/iGUyh3XyU1EsUCMu4lE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772594118; c=relaxed/simple; bh=adrxhRBK5VGSwmvLMLS00LJzCjjD2NiB2SXH8DIyaK0=; h=Date:From:To:Cc:Subject:Message-ID:MIME-Version:Content-Type: Content-Disposition; b=qhuGy1EiNM5BtI3UQo5d6YLmoiZ6bYnNCKmSx7pOUcqLeS9mwGe68qSwjRYrA01kmPvglnGYOEblck6/7zYBc8+/M/y+e26dzms9QwA4VxjHnWktUWb0w+WadxytJvorpgSLvk7iYRVTrKnveI4KBMQgow22fNT1pQ6gi+vm+LA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org; spf=pass smtp.mailfrom=chromium.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b=Q3q0goJk; arc=none smtp.client-ip=209.85.214.181 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=chromium.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="Q3q0goJk" Received: by mail-pl1-f181.google.com with SMTP id d9443c01a7336-2ae56f8776dso18486335ad.3 for ; Tue, 03 Mar 2026 19:15:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1772594115; x=1773198915; darn=vger.kernel.org; h=content-disposition:mime-version:message-id:subject:cc:to:from:date :from:to:cc:subject:date:message-id:reply-to; bh=F3ZuLgwSN0G7v9/OIE+XUVdG12gsyO2jvTrJvM7l85s=; b=Q3q0goJkdSsWm8MhB3ih5vL5mUqIS75h7WiZEg7LEHaOSdTAUsgceSak2vqpZS9ShL i4Nhum8VT9mR+UW1yzqvL3l2s30RtVEcf02b5bTHNstuJrGhyPzYkI2Umbyeep3wssQ6 Ndppi9Dtt6aWmn2C1kSlJsmDMo8NvG4lS6HGs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772594115; x=1773198915; h=content-disposition:mime-version:message-id:subject:cc:to:from:date :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=F3ZuLgwSN0G7v9/OIE+XUVdG12gsyO2jvTrJvM7l85s=; b=YKxoBHDwUPJkV34IXF/ohP7PmB2SxFCAzx5nZnm2PevXHl4/pMZJjWIDs7XVnz4Qd+ kiSiJtNQgSgwWqsEbFnbbw3FzOoWsL6n+pgUlGh2UkLl9L1OKD6OBYv7u72wzRCGXX7p RJk2dvjTisDryA2hdAFmt0FP+9VuH9puiVf0xgDE8au+1T5LqB8hotzU1KBvSU/B849O g1WBZxwvyHSahGdpkgibiGTIhaARiMkt3L8wUymaPb3mJUMKU0nXMmCIyZ/8b8t+UJt8 QiTxNHsO0o9l9/gLdjS3JV7p5D/vzo3l4GtwM2qhL/t7uxffQw7NL0J5Fn1jjeqcZYYk c33Q== X-Forwarded-Encrypted: i=1; AJvYcCWSLO1lq7vMzF6kINOO2x8oqWljO8/Rk5vYQKwRZZhFb7bjhvz9oW/R/MhCdpOiFRyKnKpMvp1Qs/mujyE=@vger.kernel.org X-Gm-Message-State: AOJu0YzQC8XTFn8IJTbL30+LVTvi54ggC+ZcDtGDFM9AQMLP1MAL+wNI rpVQqLVFTjIDlWU/GdOaDOhWQtPlwvll0DQw7WV5IwtvSTTHldC/e7R7xrpKHq309Q== X-Gm-Gg: ATEYQzy/PwO9+DbsQTn1vu6GkH0305E573xQ7l/0NYxjg1KTcmTxSyDLSkSZbsCnZ99 Cevq5qfulvqlnGMt5PsHuiHUcl5xliQmWhw+WODMls7wVfn/5pBdiLAXpEmgAoP94F7Oibmo6Bq c3SU+HMgByWg6lHg48XL2aOqkpd+Jy/64uIwfQ2RLFr0TaGeVPw1Vpm+aKPcN1rQ11fUisxifhr ZKQqxySvcYC4lY3p8VBuqIqjb1vA/d6VeZik3lh46BzMVa1QCXyMYAPiCbBAuuqWFInC2C4S+mR xFLZgJ/PT0jpryMiuhr5qHtm7qfqq9z4c+PLRGbIQqbL4WqG7dHj+UMWCFBCOmTwpDejY/m7YyC 235U+a6Tgx0ziRAHdqVOr6j217WyA/T+KxKeN2KCQTDyfnV/mY1mpZM2wP+8M5NVx6Uu58abCma PRniSrTJr12ARQ31Ar6Ua9i9KBuYCLqiGuP388kc3+yWYp1GP3+Jrn5ffyKZgt0O4= X-Received: by 2002:a17:903:1a23:b0:2ae:6579:4795 with SMTP id d9443c01a7336-2ae6aa1904dmr6603965ad.21.1772594115319; Tue, 03 Mar 2026 19:15:15 -0800 (PST) Received: from google.com ([2a00:79e0:2031:6:7218:9151:d36e:8e85]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2ae3d1b2c5esm114166475ad.6.2026.03.03.19.15.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 03 Mar 2026 19:15:14 -0800 (PST) Date: Wed, 4 Mar 2026 12:15:11 +0900 From: Sergey Senozhatsky To: Shenghao Ding , Kevin Lu , Baojun Xu Cc: Liam Girdwood , Mark Brown , Jaroslav Kysela , Takashi Iwai , linux-sound@vger.kernel.org, linux-kernel@vger.kernel.org, Sergey Senozhatsky Subject: [RFC][stable 6.6] ASoC: tas2781: ABBA deadlock in tasdevice_fw_ready() Message-ID: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Not a formal patch, just RFC. I'm seeing the following deadlock in tasdevice_fw_ready(): TaskA first takes ->codec_lock in tasdevice_fw_ready() and then ->controls_rwsem in snd_ctl_add_replace(): down_write+0x88/0xb8 snd_ctl_add+0x38/0xb0 snd_soc_add_component_controls+0xe8/0x160 tasdevice_fw_ready+0x284/0x620 request_firmware_work_func+0x54/0xa8 worker_thread+0x368/0x9d8 kthread+0x108/0x1c8 ret_from_fork+0x10/0x20 TaskB first takes ->controls_rwsem in snd_ctl_elem_read() and then ->codec_lock in tas2563_digital_gain_get(): mutex_lock+0x50/0x80 tas2563_digital_gain_get+0x4c/0x138 snd_ctl_elem_read+0xf4/0x178 snd_ctl_ioctl+0xa04/0x1430 __arm64_sys_ioctl+0x2e4/0x548 invoke_syscall+0x6c/0xe0 do_el0_svc+0x68/0xe8 el0_svc+0x34/0x88 el0t_64_sync_handler+0x1c/0xf8 el0t_64_sync+0x180/0x188 Which results in ABBA deadlock. This is seen on stable 6.6, but looking at linux-next the ABBA pattern still seem to be there (tas2563_digital_gain_get() was renamed into tasdevice_digital_gain_get()). So I have a patch that drops ->codec_lock before calling functions that add ALSA controls (which internally acquire ->controls_rwsem), and re-acquire it afterwards. snd_ctl_add() doesn't modify tas_priv members, at the same we are still in init (loading firmware) so the controls that are already visible to user space don't modify tas_priv either. (at least it seems so). Does it make sense? Or what should be the right way to fix this? --- diff --git a/sound/soc/codecs/tas2781-i2c.c b/sound/soc/codecs/tas2781-i2c.c index 41b89fcc69c3..18c8c7471301 100644 --- a/sound/soc/codecs/tas2781-i2c.c +++ b/sound/soc/codecs/tas2781-i2c.c @@ -1638,7 +1638,19 @@ static void tasdevice_fw_ready(const struct firmware= *fmw, tasdevice_config_info_remove(tas_priv); goto out; } + + /* + * Release codec_lock before adding ALSA controls to avoid ABBA + * deadlock: the ALSA core acquires controls_rwsem (read) before + * calling kcontrol .get/.put callbacks which then take codec_lock, + * establishing the lock order controls_rwsem -> codec_lock. + * Calling snd_ctl_add() (via snd_soc_add_component_controls()) + * under codec_lock would acquire controls_rwsem (write) under + * codec_lock, inverting the lock order. + */ + mutex_unlock(&tas_priv->codec_lock); tasdevice_create_control(tas_priv); + mutex_lock(&tas_priv->codec_lock); =20 tasdevice_dsp_remove(tas_priv); tasdevice_calbin_remove(tas_priv); @@ -1675,8 +1687,11 @@ static void tasdevice_fw_ready(const struct firmware= *fmw, =20 /* * If no dsp-related kcontrol created, the dsp resource will be freed. + * Release codec_lock before adding controls (see comment above). */ + mutex_unlock(&tas_priv->codec_lock); ret =3D tasdevice_dsp_create_ctrls(tas_priv); + mutex_lock(&tas_priv->codec_lock); if (ret) { dev_err(tas_priv->dev, "dsp controls error\n"); goto out; @@ -1685,7 +1700,9 @@ static void tasdevice_fw_ready(const struct firmware = *fmw, =20 /* There is no calibration required for TAS58XX. */ if (tas_priv->chip_id < TAS5802) { + mutex_unlock(&tas_priv->codec_lock); ret =3D tasdevice_create_cali_ctrls(tas_priv); + mutex_lock(&tas_priv->codec_lock); if (ret) { dev_err(tas_priv->dev, "cali controls error\n"); goto out;