From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from metis.whiteo.stw.pengutronix.de (metis.whiteo.stw.pengutronix.de [185.203.201.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 59D7F1D5160 for ; Wed, 4 Mar 2026 10:57:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.203.201.7 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772621826; cv=none; b=Ss+hUMNzoIHHWWzTgccmJobyVFTKqinC2xoMnqFdajKEyoRXm/atpLsVLeYrrxEEVW6f+Kb2LZDclJbF4oBE0DgqWDUf0JqEyKpD6VWYsYRXgXfpdEnmZbH3Ma0aHYYZzERdfTeZQpYsBAlDF45BV9q9LwEbIchG/UOuetEmGuQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772621826; c=relaxed/simple; bh=rg8OqonmsZsoTA8BaC4ZPyj7lN/+cFmzJO8eZZ7lnFY=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=aM17tPJTF1ciwvt7HaVCIsbRtntwPknTjAJWUwoyob60EbCLZ0fmYsmwOtsmeAOWPZenCyHBPPcG6xVfSt4GdXwfAlIKpXqZ1njtCXjNi2WXal1Or9Nd8k5GIEV4Mf/9+TGLwvstssqoVUENBRACcDm/iOkJoZqMS/Nydo0Ok1g= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=pengutronix.de; spf=pass smtp.mailfrom=pengutronix.de; arc=none smtp.client-ip=185.203.201.7 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=pengutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=pengutronix.de Received: from drehscheibe.grey.stw.pengutronix.de ([2a0a:edc0:0:c01:1d::a2]) by metis.whiteo.stw.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1vxjuX-0004in-Tg; Wed, 04 Mar 2026 11:57:01 +0100 Received: from lupine.office.stw.pengutronix.de ([2a0a:edc0:0:900:1d::4e] helo=lupine) by drehscheibe.grey.stw.pengutronix.de with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vxjuW-003hP5-1F; Wed, 04 Mar 2026 11:57:01 +0100 Received: from pza by lupine with local (Exim 4.98.2) (envelope-from ) id 1vxjuX-000000007km-2lwq; Wed, 04 Mar 2026 11:57:01 +0100 Message-ID: Subject: Re: [PATCH v2 10/14] reset: protect struct reset_control with its own mutex From: Philipp Zabel To: Bartosz Golaszewski , Krzysztof Kozlowski Cc: linux-kernel@vger.kernel.org Date: Wed, 04 Mar 2026 11:57:01 +0100 In-Reply-To: <20260223-reset-core-refactor-v2-10-5e5a7289190c@oss.qualcomm.com> References: <20260223-reset-core-refactor-v2-0-5e5a7289190c@oss.qualcomm.com> <20260223-reset-core-refactor-v2-10-5e5a7289190c@oss.qualcomm.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.56.2-0+deb13u1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-SA-Exim-Connect-IP: 2a0a:edc0:0:c01:1d::a2 X-SA-Exim-Mail-From: p.zabel@pengutronix.de X-SA-Exim-Scanned: No (on metis.whiteo.stw.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-kernel@vger.kernel.org On Mo, 2026-02-23 at 11:06 +0100, Bartosz Golaszewski wrote: > Currently we use a single, global mutex - misleadingly names > reset_list_mutex - to protect the global list of reset devices, > per-controller list of reset control handles and also internal fields of > struct reset_control. Locking can be made a lot more fine-grained if we > use a separate mutex for serializing operations on the list AND > accessing the reset control handle. >=20 > Signed-off-by: Bartosz Golaszewski > --- > drivers/reset/core.c | 38 ++++++++++++++------------------------ > 1 file changed, 14 insertions(+), 24 deletions(-) >=20 > diff --git a/drivers/reset/core.c b/drivers/reset/core.c > index d4813c712abf3df7993b0c2be1fe292b89241d11..647e7112779517d2425f55728= e1e7fb6e76a8045 100644 > --- a/drivers/reset/core.c > +++ b/drivers/reset/core.c > @@ -49,6 +49,7 @@ static DEFINE_IDA(reset_gpio_ida); > * @triggered_count: Number of times this reset line has been reset. Cur= rently > * only used for shared resets, which means that the v= alue > * will be either 0 or 1. > + * @lock: Serializes access to other fields of this structure This is not correct, the lock only serializes reset_control_acquire(). > */ > struct reset_control { > struct reset_controller_dev __rcu *rcdev; > @@ -61,6 +62,7 @@ struct reset_control { > bool array; > atomic_t deassert_count; > atomic_t triggered_count; > + struct mutex lock; > }; > =20 > /** > @@ -707,7 +709,7 @@ int reset_control_acquire(struct reset_control *rstc) > if (reset_control_is_array(rstc)) > return reset_control_array_acquire(rstc_to_array(rstc)); > =20 > - guard(mutex)(&reset_list_mutex); > + guard(mutex)(&rstc->lock); > =20 > if (rstc->acquired) > return 0; > @@ -859,6 +861,7 @@ __reset_control_get_internal(struct reset_controller_= dev *rcdev, > list_add(&rstc->list, &rcdev->reset_control_head); > rstc->id =3D index; > kref_init(&rstc->refcnt); > + mutex_init(&rstc->lock); > rstc->acquired =3D acquired; > rstc->shared =3D shared; > get_device(rcdev->dev); > @@ -872,8 +875,6 @@ static void __reset_control_release(struct kref *kref= ) > refcnt); > struct reset_controller_dev *rcdev; > =20 > - lockdep_assert_held(&reset_list_mutex); > - > scoped_guard(srcu, &rstc->srcu) { > rcdev =3D rcu_replace_pointer(rstc->rcdev, NULL, true); > if (rcdev) { > @@ -882,15 +883,14 @@ static void __reset_control_release(struct kref *kr= ef) > } > } > =20 > + mutex_destroy(&rstc->lock); > synchronize_srcu(&rstc->srcu); > cleanup_srcu_struct(&rstc->srcu); > kfree(rstc); > } > =20 > -static void __reset_control_put_internal(struct reset_control *rstc) > +static void reset_control_put_internal(struct reset_control *rstc) > { > - lockdep_assert_held(&reset_list_mutex); > - With this, reset_control_put() is not serialized against reset_control_get() anymore. A __reset_control_get_internal(), running concurrently under rcdev- >lock, might find this rstc right before __reset_control_release() starts tearing it down. regards Philipp