Received: by 2002:a05:7412:419a:b0:f3:1519:9f41 with SMTP id i26csp3544606rdh; Mon, 27 Nov 2023 17:55:40 -0800 (PST) X-Google-Smtp-Source: AGHT+IFTA7/I0DxYNJKPZ3DNPH5XTWsxWu9Ksgg7QAsrQ4bsrTn+lucmfPj9ZFPdoZuaO3+0E+lg X-Received: by 2002:a05:6830:6b42:b0:6d6:4805:45aa with SMTP id dc2-20020a0568306b4200b006d6480545aamr14727188otb.8.1701136540303; Mon, 27 Nov 2023 17:55:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1701136540; cv=none; d=google.com; s=arc-20160816; b=RFT+V7muM/iznI19CD9EmNnuQhTbMDjsZCBf2gI8cUKOAUd6LvlgIQFOcyWSLCC26l 5lgJK4bFhQJEiQOzFDjIdG7yYmYO4b3sh/GczLOQPsOcsjfRWpfJFX3v85Xh/quKsJHe w4DeB2dEdhwFjamlXh9xFXZSGu75WpVs/BpIQtEPQy+ZddqAtk7z0zBUe4M8iXA6O6GM DmXyKMBvqnsQLluiRqvH4SU0Q8HI3jO8mBpRbxg8mg0YQ5qfA5T+XPCJ+ReGSZzQUoPD Hv9u9EYflVwvz6ATkipi3RoCN+MXJ7tqnkGXyG5RcQft+nUJievP6tUW2S3d0a0fhPFd 2Uag== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=NHu+lqeWh4DisTkj49UpVbjWkoKf/V0c7GXH9eX4XIw=; fh=SrDlbgi+ZnGJ5PiZXDafruj+WIm9LL1xKmzsDDxkRmc=; b=pu9tLBbC1BKg2oQjSUVErtSOXa30GiMhYcHGROOjvGLDWIQpRtqr2TjkUa6pqhZ0UH cIKo0Q7g0Bh2B3ueC742aqRoX1PoDL8jSGAbxMzDuaRf5wAy9yoP1ryvSlFFlhHfp/xR ml9SwOMiEd40ooSIIZ0/z8lQCpl24G6OT7VFhGSiiF3qTKB+t2c3o8diSIKiaqOlDcfN 2UwSUM9cKVbOTN6kvkfNQC9QCdAzMAZSFfDM6Y7QQlUyTUr8nYfvTM8KHyxmellfCoZv nRxTMtbYcUP7o+P94S7GgCrFN+Klw/rAsg6bZlQT8TppIVb4ek76WYqaOce0znNrSJx/ ywdw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=jEFNwwB9; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from lipwig.vger.email (lipwig.vger.email. [23.128.96.33]) by mx.google.com with ESMTPS id t2-20020a654082000000b00577f87e6210si11382048pgp.332.2023.11.27.17.55.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 27 Nov 2023 17:55:40 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) client-ip=23.128.96.33; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=jEFNwwB9; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by lipwig.vger.email (Postfix) with ESMTP id 5285680A13BE; Mon, 27 Nov 2023 17:55:37 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at lipwig.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232573AbjK1BzU (ORCPT + 99 others); Mon, 27 Nov 2023 20:55:20 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48174 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229488AbjK1BzT (ORCPT ); Mon, 27 Nov 2023 20:55:19 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 03D2E1A7 for ; Mon, 27 Nov 2023 17:55:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1701136524; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=NHu+lqeWh4DisTkj49UpVbjWkoKf/V0c7GXH9eX4XIw=; b=jEFNwwB9nF/d6URgxbafgFhk5e7gLTSqp8gWATZYghYfZewWkXe+7QmHtiXxD+rR8+Hb1O Q5ngCsYm/2P3hm0V1iKGv2GX6o4c1TPtgWj/C4PGNEJ+Bij3HVvg0SwT7R8xLHDKHI36HP rDo1FxGO1a2P2rwaDTOvmTR01lrAXPI= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-557-WkLp9sgrMQeVCRzucbnBNg-1; Mon, 27 Nov 2023 20:55:20 -0500 X-MC-Unique: WkLp9sgrMQeVCRzucbnBNg-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 90B2685A5BD; Tue, 28 Nov 2023 01:55:19 +0000 (UTC) Received: from [10.22.8.93] (unknown [10.22.8.93]) by smtp.corp.redhat.com (Postfix) with ESMTP id E1DF740C6EB9; Tue, 28 Nov 2023 01:55:18 +0000 (UTC) Message-ID: Date: Mon, 27 Nov 2023 20:55:18 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH 1/1] locking: introduce devm_mutex_init and devm_mutex_destroy Content-Language: en-US To: George Stark , peterz@infradead.org, mingo@redhat.com, will@kernel.org, boqun.feng@gmail.com, andriy.shevchenko@linux.intel.com, jic23@kernel.org Cc: linux-kernel@vger.kernel.org, kernel@salutedevices.com References: <20231128000910.73784-1-gnstark@salutedevices.com> From: Waiman Long In-Reply-To: <20231128000910.73784-1-gnstark@salutedevices.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.2 X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lipwig.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (lipwig.vger.email [0.0.0.0]); Mon, 27 Nov 2023 17:55:37 -0800 (PST) On 11/27/23 19:09, George Stark wrote: > Using of devm API leads to 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() and devm_mutex_destroy(). > > Signed-off-by: George Stark > --- > include/linux/mutex.h | 3 +++ > kernel/locking/mutex.c | 37 +++++++++++++++++++++++++++++++++++++ > 2 files changed, 40 insertions(+) > > diff --git a/include/linux/mutex.h b/include/linux/mutex.h > index a33aa9eb9fc3..7f60cd842322 100644 > --- a/include/linux/mutex.h > +++ b/include/linux/mutex.h > @@ -119,6 +119,9 @@ do { \ > extern void __mutex_init(struct mutex *lock, const char *name, > struct lock_class_key *key); > > +int devm_mutex_init(struct device *dev, struct mutex *lock); > +void devm_mutex_destroy(struct device *dev, struct mutex *lock); > + > /** > * mutex_is_locked - is the mutex locked > * @lock: the mutex to be queried > diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c > index d973fe6041bf..a73124719dcb 100644 > --- a/kernel/locking/mutex.c > +++ b/kernel/locking/mutex.c > @@ -56,6 +56,43 @@ __mutex_init(struct mutex *lock, const char *name, struct lock_class_key *key) > } > EXPORT_SYMBOL(__mutex_init); > > +static void devm_mutex_release(struct device *dev, void *res) > +{ > + mutex_destroy(*(struct mutex **)res); > +} > + > +static int devm_mutex_match(struct device *dev, void *res, void *data) > +{ > + struct mutex **r = res; > + > + if (WARN_ON(!r || !*r)) > + return 0; > + > + return *r == data; > +} > + > +int devm_mutex_init(struct device *dev, struct mutex *lock) > +{ > + struct mutex **ptr; > + > + ptr = devres_alloc(devm_mutex_release, sizeof(*ptr), GFP_KERNEL); > + if (!ptr) > + return -ENOMEM; > + > + mutex_init(lock); > + > + *ptr = lock; > + devres_add(dev, ptr); > + return 0; > +} > +EXPORT_SYMBOL(devm_mutex_init); > + > +void devm_mutex_destroy(struct device *dev, struct mutex *lock) > +{ > + devres_release(dev, devm_mutex_release, devm_mutex_match, lock); > +} > +EXPORT_SYMBOL(devm_mutex_destroy); > + > /* > * @owner: contains: 'struct task_struct *' to the current lock owner, > * NULL means not owned. Since task_struct pointers are aligned at These APIs are specific to devres. I don't believe it is suitable to put them into the generic mutex.h header file. All devres_* functions are defined in include/linux/device.h which is probabably not included in mutex.h. You may consider putting these APIs into device.h instead. Cheers, Longman