[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20260203113328.REAPqQL6@linutronix.de>
Date: Tue, 3 Feb 2026 12:33:28 +0100
From: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To: Thomas Böhler <witcher@...edspace.de>
Cc: Clark Williams <clrkwllms@...nel.org>,
Steven Rostedt <rostedt@...dmis.org>, linux-kernel@...r.kernel.org,
linux-rt-devel@...ts.linux.dev
Subject: Re: [PATCH] rtmutex: Introduce __cleanup() based infrastructure
On 2026-02-02 19:59:43 [+0100], Thomas Böhler wrote:
> > Do you plan to have any users of this?
>
> No. I discovered this was "missing" while developing out-of-tree. I'm
> aware that an interface should have in-tree users, but I'm also a bit
> confused about who is using rt_mutex in-tree in the first place as it
> looks like there are only a handful of users.
>
> I'll make sure to do more research before I might post a v2.
>
> Please do tell me if this isn't going to be merged due to missing users,
> I'll drop this then. No problem, and sorry for the noise if that's the
> case. :)
if you grep for rt_mutex_unlock() you should see the users. Most of it
API which is unlikely to use it because not every lock has its matching
unlock within the scope.
The rcu user a bit "odd" so it would important to not get the compiler
to optimize it away (in case it would do such a thing).
The selftest is already complicated as well as the torture.
Most of the i2c abstracts its away so it can't use it.
This leaves us only with em28xx-i2c.c as the only possible user in-tree
if I did look right.
Sebastian
Powered by blists - more mailing lists