Messages in this thread | | | From | Andy Shevchenko <> | Date | Fri, 15 Dec 2023 17:58:44 +0200 | Subject | Re: [PATCH RFC v4-bis] locking: introduce devm_mutex_init |
| |
On Fri, Dec 15, 2023 at 8:23 AM Christophe Leroy <christophe.leroy@csgroup.eu> wrote: > > From: George Stark <gnstark@salutedevices.com> > > 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()
Missing period.
...
> } while (0) > #endif /* CONFIG_PREEMPT_RT */
^^^ (1)
> +struct device; > + > +/* > + * devm_mutex_init() registers a function that calls mutex_destroy() > + * when the ressource is released. > + * > + * When mutex_destroy() is a not, there is no need to register that > + * function. > + */ > +#ifdef CONFIG_DEBUG_MUTEXES
Shouldn't this be
#if defined(CONFIG_DEBUG_MUTEXES) && !defined(CONFIG_PREEMPT_RT)
(see (1) as well)?
> +void mutex_destroy(struct mutex *lock); > +int devm_mutex_init(struct device *dev, struct mutex *lock); > +#else > +static inline void mutex_destroy(struct mutex *lock) {} > + > +static inline int devm_mutex_init(struct device *dev, struct mutex *lock) > +{ > + mutex_init(lock); > + return 0; > +} > +#endif
-- With Best Regards, Andy Shevchenko
| |