Commit 54da6a092431 ("locking: Introduce __cleanup() based
infrastructure") introduced lock guards for mutexes in
include/linux/mutex.h, but, presumably as PREEMPT_RT wasn't merged at
the time, the guard for rt_mutex was never created. Do this now so this
infrastructure exists for rt_mutex as well.

Signed-off-by: Thomas Böhler <witcher@wiredspace.de>
---
 include/linux/rtmutex.h | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/include/linux/rtmutex.h b/include/linux/rtmutex.h
index ede4c6bf6f22..3c766eba2c7d 100644
--- a/include/linux/rtmutex.h
+++ b/include/linux/rtmutex.h
@@ -17,6 +17,7 @@
 #include <linux/linkage.h>
 #include <linux/rbtree_types.h>
 #include <linux/spinlock_types_raw.h>
+#include <linux/cleanup.h>
 
 extern int max_lock_depth;
 
@@ -129,4 +130,8 @@ extern int rt_mutex_trylock(struct rt_mutex *lock);
 
 extern void rt_mutex_unlock(struct rt_mutex *lock);
 
+DEFINE_GUARD(rt_mutex, struct rt_mutex *, rt_mutex_lock(_T), rt_mutex_unlock(_T))
+DEFINE_GUARD_COND(rt_mutex, _try, rt_mutex_trylock(_T))
+DEFINE_GUARD_COND(rt_mutex, _intr, rt_mutex_lock_interruptible(_T), _RET == 0)
+
 #endif

---
base-commit: 18f7fcd5e69a04df57b563360b88be72471d6b62
change-id: 20260202-rt_mutex-guard-bfa1518b4f13

Best regards,
-- 
Thomas Böhler <witcher@wiredspace.de>

On 2026-02-02 18:04:43 [+0100], Thomas Böhler wrote:
> Commit 54da6a092431 ("locking: Introduce __cleanup() based
> infrastructure") introduced lock guards for mutexes in
> include/linux/mutex.h, but, presumably as PREEMPT_RT wasn't merged at
> the time, the guard for rt_mutex was never created. Do this now so this
> infrastructure exists for rt_mutex as well.

Wait, what? rt_mutex can be used independently of PREEMPT_RT.
I suggest you focus on what this patch does in its description and
repost it with the locking maintainer in Cc.

Do you plan to have any users of this?

> Signed-off-by: Thomas Böhler <witcher@wiredspace.de>

Sebastian

On Mon Feb 2, 2026 at 6:58 PM CET, Sebastian Andrzej Siewior wrote:
> On 2026-02-02 18:04:43 [+0100], Thomas Böhler wrote:
>> Commit 54da6a092431 ("locking: Introduce __cleanup() based
>> infrastructure") introduced lock guards for mutexes in
>> include/linux/mutex.h, but, presumably as PREEMPT_RT wasn't merged at
>> the time, the guard for rt_mutex was never created. Do this now so this
>> infrastructure exists for rt_mutex as well.
>
> Wait, what? rt_mutex can be used independently of PREEMPT_RT.

I wasn't aware of that, sorry for the confusion. I'm still pretty
new to the Linux Kernel; my assumption was wrong here.

> I suggest you focus on what this patch does in its description and
> repost it with the locking maintainer in Cc.

Thanks, I'll do that for a potential v2!

> 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. :)

>> Signed-off-by: Thomas Böhler <witcher@wiredspace.de>
>
> Sebastian

-- 
Thomas Böhler

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