From patchwork Thu Mar 14 20:18:49 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: George Stark X-Patchwork-Id: 780426 Received: from mx1.sberdevices.ru (mx2.sberdevices.ru [45.89.224.132]) (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 833AA2A1C7; Thu, 14 Mar 2024 20:19:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.89.224.132 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710447563; cv=none; b=qHxMXfpLs+sDat1QUznVQhgHVEYPxuq0bqkor3s0Ai1HthPbNfjSRM7zxV6Bq6NO9rybgBjUXoJxc081l2w4DY10NuQx+MqaDa9JsSFTbXH+/3Uf58f4aEdKsS70IYnqa9IgV2+wd+GRz4bnTwXYKVZRbSH1WXwFyDKkYTiKP6U= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710447563; c=relaxed/simple; bh=JHyl/KzE3UVf7c1HemLBzMYh2tUmE6uiuV5f5ZzDrCs=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=JATpKM2/5AbdrwqtHE6HT+bIE1hD9PbP02q2Dr6eEE/wFejZ9PF96eEzxN/KV5ivK/CwqjNerSZKkWYBOwdkDZQQgNEz0oj1nMwrGsqkb+iuPyEn+PfBdJHm+23HkkOFU/GXs6sA//xnI7vSIbNea2OUMq2696QFjwfdBN35dzk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=salutedevices.com; spf=pass smtp.mailfrom=salutedevices.com; dkim=pass (2048-bit key) header.d=salutedevices.com header.i=@salutedevices.com header.b=J1Cs67a4; arc=none smtp.client-ip=45.89.224.132 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=salutedevices.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=salutedevices.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=salutedevices.com header.i=@salutedevices.com header.b="J1Cs67a4" Received: from p-infra-ksmg-sc-msk02 (localhost [127.0.0.1]) by mx1.sberdevices.ru (Postfix) with ESMTP id B0236120008; Thu, 14 Mar 2024 23:19:16 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.sberdevices.ru B0236120008 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salutedevices.com; s=mail; t=1710447556; bh=TIopjX9JsFChW/Sn1tGpd/8lUgeh5NxQ6ZHfgAAkmD4=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type:From; b=J1Cs67a4f7grZInNTHO4X5XtJdvq3QROxfnZ7OWp6bX2ulB3RypVi6dEpJkv2cjEu r6hxukx40WE4rC2My6hhFGehfBVkps7hWj3+5RavAEkZ+M0hDy8y5vK6gOtcEw4nKt R6WKPFkL9gD3ziRxCbag+zG9S+CPQyvympNpOPt+XnHQji+pVW9oHPoHkWOLig+TuM a4h+hxqrwJ0FgCyrpyk4oyv/D+zTMFy1GoQbXe2/vVLLQRKvsV2x5R367N/Pm/cTrM AT8CBIND3kLpkHTMCUYrwjI8MuUgOsrHkxP4pa7qNaWMRKPcEBUmzhlTjfOth4Qyo9 NydDgNKCwC/QA== Received: from smtp.sberdevices.ru (p-i-exch-sc-m02.sberdevices.ru [172.16.192.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.sberdevices.ru (Postfix) with ESMTPS; Thu, 14 Mar 2024 23:19:16 +0300 (MSK) Received: from work.sberdevices.ru (100.64.160.123) by p-i-exch-sc-m02.sberdevices.ru (172.16.192.103) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.40; Thu, 14 Mar 2024 23:19:16 +0300 From: George Stark To: , , , , , , , , , , , , , , CC: , , , George Stark Subject: [PATCH v7 1/8] locking/mutex: introduce devm_mutex_init() Date: Thu, 14 Mar 2024 23:18:49 +0300 Message-ID: <20240314201856.1991899-2-gnstark@salutedevices.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20240314201856.1991899-1-gnstark@salutedevices.com> References: <20240314201856.1991899-1-gnstark@salutedevices.com> Precedence: bulk X-Mailing-List: linux-leds@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-ClientProxiedBy: p-i-exch-sc-m01.sberdevices.ru (172.16.192.107) To p-i-exch-sc-m02.sberdevices.ru (172.16.192.103) X-KSMG-Rule-ID: 10 X-KSMG-Message-Action: clean X-KSMG-AntiSpam-Lua-Profiles: 183875 [Feb 29 2024] X-KSMG-AntiSpam-Version: 6.1.0.3 X-KSMG-AntiSpam-Envelope-From: gnstark@salutedevices.com X-KSMG-AntiSpam-Rate: 0 X-KSMG-AntiSpam-Status: not_detected X-KSMG-AntiSpam-Method: none X-KSMG-AntiSpam-Auth: dkim=none X-KSMG-AntiSpam-Info: LuaCore: 7 0.3.7 6d6bf5bd8eea7373134f756a2fd73e9456bb7d1a, {Tracking_from_domain_doesnt_match_to}, FromAlignment: s, ApMailHostAddress: 100.64.160.123 X-MS-Exchange-Organization-SCL: -1 X-KSMG-AntiSpam-Interceptor-Info: scan successful X-KSMG-AntiPhishing: Clean X-KSMG-LinksScanning: Clean X-KSMG-AntiVirus: Kaspersky Secure Mail Gateway, version 2.0.1.6960, bases: 2024/02/29 19:21:00 #23899999 X-KSMG-AntiVirus-Status: Clean, skipped Using of devm API leads to a certain order of releasing resources. So all dependent resources which are not devm-wrapped should be deleted with respect to devm-release order. Mutex is one of such objects that often is bound to other resources and has no own devm wrapping. Since mutex_destroy() actually does nothing in non-debug builds frequently calling mutex_destroy() is just ignored which is safe for now but wrong formally and can lead to a problem if mutex_destroy() will be extended so introduce devm_mutex_init(). Suggested-by: Christophe Leroy Signed-off-by: George Stark Reviewed-by: Christophe Leroy Reviewed-by: Andy Shevchenko Reviewed-by: Marek Behún Acked-by: Waiman Long --- include/linux/mutex.h | 27 +++++++++++++++++++++++++++ kernel/locking/mutex-debug.c | 11 +++++++++++ 2 files changed, 38 insertions(+) diff --git a/include/linux/mutex.h b/include/linux/mutex.h index 67edc4ca2bee..a561c629d89f 100644 --- a/include/linux/mutex.h +++ b/include/linux/mutex.h @@ -22,6 +22,8 @@ #include #include +struct device; + #ifdef CONFIG_DEBUG_LOCK_ALLOC # define __DEP_MAP_MUTEX_INITIALIZER(lockname) \ , .dep_map = { \ @@ -117,6 +119,31 @@ do { \ } while (0) #endif /* CONFIG_PREEMPT_RT */ +#ifdef CONFIG_DEBUG_MUTEXES + +int __devm_mutex_init(struct device *dev, struct mutex *lock); + +#else + +static inline int __devm_mutex_init(struct device *dev, struct mutex *lock) +{ + /* + * When CONFIG_DEBUG_MUTEXES is off mutex_destroy() is just a nop so + * no really need to register it in the devm subsystem. + */ + return 0; +} + +#endif + +#define devm_mutex_init(dev, mutex) \ +({ \ + typeof(mutex) mutex_ = (mutex); \ + \ + mutex_init(mutex_); \ + __devm_mutex_init(dev, mutex_); \ +}) + /* * See kernel/locking/mutex.c for detailed documentation of these APIs. * Also see Documentation/locking/mutex-design.rst. diff --git a/kernel/locking/mutex-debug.c b/kernel/locking/mutex-debug.c index bc8abb8549d2..f7e848defd50 100644 --- a/kernel/locking/mutex-debug.c +++ b/kernel/locking/mutex-debug.c @@ -12,6 +12,7 @@ */ #include #include +#include #include #include #include @@ -89,6 +90,16 @@ void debug_mutex_init(struct mutex *lock, const char *name, lock->magic = lock; } +static void devm_mutex_release(void *res) +{ + mutex_destroy(res); +} + +int __devm_mutex_init(struct device *dev, struct mutex *lock) +{ + return devm_add_action_or_reset(dev, devm_mutex_release, lock); +} + /*** * mutex_destroy - mark a mutex unusable * @lock: the mutex to be destroyed