Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) client-ip=2620:137:e000::3:5;
Date:   Tue, 28 Nov 2023 17:45:35 +0100
From:   Peter Zijlstra <peterz@infradead.org>
To:     George Stark <gnstark@salutedevices.com>
Cc:     mingo@redhat.com, will@kernel.org, longman@redhat.com,
        boqun.feng@gmail.com, andriy.shevchenko@linux.intel.com,
        jic23@kernel.org, linux-kernel@vger.kernel.org,
        kernel@salutedevices.com
Subject: Re: [RFC PATCH 1/1] locking: introduce devm_mutex_init and
 devm_mutex_destroy
Message-ID: <20231128164535.GT8262@noisy.programming.kicks-ass.net>
References: <20231128000910.73784-1-gnstark@salutedevices.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20231128000910.73784-1-gnstark@salutedevices.com>
Precedence: bulk

On Tue, Nov 28, 2023 at 03:09:10AM +0300, 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().
> 

Aside of the issue raised by Waiman, it is also very undesirable to
introduce EXPORT'ed symbols without a user. Please group this with a
patch that actually makes use of it.

No in-tree users, no export.