[19/50] locking/mutex: split out mutex_types.h
Commit Message
Trimming down sched.h dependencies: we don't want to include more than
the base types.
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Will Deacon <will@kernel.org>
Cc: Waiman Long <longman@redhat.com>
Cc: Boqun Feng <boqun.feng@gmail.com>
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
---
include/linux/mutex.h | 52 +--------------------------
include/linux/mutex_types.h | 71 +++++++++++++++++++++++++++++++++++++
include/linux/sched.h | 2 +-
3 files changed, 73 insertions(+), 52 deletions(-)
create mode 100644 include/linux/mutex_types.h
Comments
On 12/15/23 22:26, Kent Overstreet wrote:
> Trimming down sched.h dependencies: we don't want to include more than
> the base types.
>
> Signed-off-by: Kent Overstreet<kent.overstreet@linux.dev>
> Cc: Peter Zijlstra<peterz@infradead.org>
> Cc: Ingo Molnar<mingo@redhat.com>
> Cc: Will Deacon<will@kernel.org>
> Cc: Waiman Long<longman@redhat.com>
> Cc: Boqun Feng<boqun.feng@gmail.com>
> Signed-off-by: Kent Overstreet<kent.overstreet@linux.dev>
> ---
> include/linux/mutex.h | 52 +--------------------------
> include/linux/mutex_types.h | 71 +++++++++++++++++++++++++++++++++++++
> include/linux/sched.h | 2 +-
> 3 files changed, 73 insertions(+), 52 deletions(-)
> create mode 100644 include/linux/mutex_types.h
>
> diff --git a/include/linux/mutex.h b/include/linux/mutex.h
> index a33aa9eb9fc3..0dfba5df6524 100644
> --- a/include/linux/mutex.h
> +++ b/include/linux/mutex.h
> @@ -20,6 +20,7 @@
> #include <linux/osq_lock.h>
> #include <linux/debug_locks.h>
> #include <linux/cleanup.h>
> +#include <linux/mutex_types.h>
>
> #ifdef CONFIG_DEBUG_LOCK_ALLOC
> # define __DEP_MAP_MUTEX_INITIALIZER(lockname) \
> @@ -33,49 +34,6 @@
>
> #ifndef CONFIG_PREEMPT_RT
>
> -/*
> - * Simple, straightforward mutexes with strict semantics:
> - *
> - * - only one task can hold the mutex at a time
> - * - only the owner can unlock the mutex
> - * - multiple unlocks are not permitted
> - * - recursive locking is not permitted
> - * - a mutex object must be initialized via the API
> - * - a mutex object must not be initialized via memset or copying
> - * - task may not exit with mutex held
> - * - memory areas where held locks reside must not be freed
> - * - held mutexes must not be reinitialized
> - * - mutexes may not be used in hardware or software interrupt
> - * contexts such as tasklets and timers
> - *
> - * These semantics are fully enforced when DEBUG_MUTEXES is
> - * enabled. Furthermore, besides enforcing the above rules, the mutex
> - * debugging code also implements a number of additional features
> - * that make lock debugging easier and faster:
> - *
> - * - uses symbolic names of mutexes, whenever they are printed in debug output
> - * - point-of-acquire tracking, symbolic lookup of function names
> - * - list of all locks held in the system, printout of them
> - * - owner tracking
> - * - detects self-recursing locks and prints out all relevant info
> - * - detects multi-task circular deadlocks and prints out all affected
> - * locks and tasks (and only those tasks)
> - */
> -struct mutex {
> - atomic_long_t owner;
> - raw_spinlock_t wait_lock;
> -#ifdef CONFIG_MUTEX_SPIN_ON_OWNER
> - struct optimistic_spin_queue osq; /* Spinner MCS lock */
> -#endif
> - struct list_head wait_list;
> -#ifdef CONFIG_DEBUG_MUTEXES
> - void *magic;
> -#endif
> -#ifdef CONFIG_DEBUG_LOCK_ALLOC
> - struct lockdep_map dep_map;
> -#endif
> -};
> -
> #ifdef CONFIG_DEBUG_MUTEXES
>
> #define __DEBUG_MUTEX_INITIALIZER(lockname) \
> @@ -131,14 +89,6 @@ extern bool mutex_is_locked(struct mutex *lock);
> /*
> * Preempt-RT variant based on rtmutexes.
> */
> -#include <linux/rtmutex.h>
Including rtmutex.h here means that mutex_types.h is no longer a simple
header for types only. So unless you also break out a rtmutex_types.h,
it is inconsistent.
Besides, the kernel/sched code does use mutex_lock/unlock calls quite
frequently. With this patch, mutex.h will not be directly included. I
suspect that it is indirectly included via other header files. This may
be an issue with some configurations.
Cheers, Longman
On Mon, Dec 18, 2023 at 11:53:08AM -0500, Waiman Long wrote:
> On 12/15/23 22:26, Kent Overstreet wrote:
> > -#include <linux/rtmutex.h>
>
> Including rtmutex.h here means that mutex_types.h is no longer a simple
> header for types only. So unless you also break out a rtmutex_types.h, it is
> inconsistent.
good observation, I'll have to leave it for the next round of cleanups
though since the merge window is approaching and I'll have to redo all
the testing.
> Besides, the kernel/sched code does use mutex_lock/unlock calls quite
> frequently. With this patch, mutex.h will not be directly included. I
> suspect that it is indirectly included via other header files. This may be
> an issue with some configurations.
I've now put it through randconfig testing on every arch that debian
includes a compiler for (excluding sh and xtensa, which throw internal
compiler errors) and that one hasn't come up yet.
could still be included indirectly though - I haven't checked for that
one specifically yet.
On 12/18/23 20:46, Kent Overstreet wrote:
> On Mon, Dec 18, 2023 at 11:53:08AM -0500, Waiman Long wrote:
>> On 12/15/23 22:26, Kent Overstreet wrote:
>>> -#include <linux/rtmutex.h>
>> Including rtmutex.h here means that mutex_types.h is no longer a simple
>> header for types only. So unless you also break out a rtmutex_types.h, it is
>> inconsistent.
> good observation, I'll have to leave it for the next round of cleanups
> though since the merge window is approaching and I'll have to redo all
> the testing.
>
>> Besides, the kernel/sched code does use mutex_lock/unlock calls quite
>> frequently. With this patch, mutex.h will not be directly included. I
>> suspect that it is indirectly included via other header files. This may be
>> an issue with some configurations.
> I've now put it through randconfig testing on every arch that debian
> includes a compiler for (excluding sh and xtensa, which throw internal
> compiler errors) and that one hasn't come up yet.
>
> could still be included indirectly though - I haven't checked for that
> one specifically yet.
If you are replacing mutex.h in include/linux/sched.h by mutex_types.h,
I would suggest you add mutex.h to kernel/sched/sched.h to ensure this
header file is included by the scheduler code.
Cheers,
Longman
On Mon, Dec 18, 2023 at 10:04:39PM -0500, Waiman Long wrote:
>
> On 12/18/23 20:46, Kent Overstreet wrote:
> > On Mon, Dec 18, 2023 at 11:53:08AM -0500, Waiman Long wrote:
> > > On 12/15/23 22:26, Kent Overstreet wrote:
> > > > -#include <linux/rtmutex.h>
> > > Including rtmutex.h here means that mutex_types.h is no longer a simple
> > > header for types only. So unless you also break out a rtmutex_types.h, it is
> > > inconsistent.
> > good observation, I'll have to leave it for the next round of cleanups
> > though since the merge window is approaching and I'll have to redo all
> > the testing.
> >
> > > Besides, the kernel/sched code does use mutex_lock/unlock calls quite
> > > frequently. With this patch, mutex.h will not be directly included. I
> > > suspect that it is indirectly included via other header files. This may be
> > > an issue with some configurations.
> > I've now put it through randconfig testing on every arch that debian
> > includes a compiler for (excluding sh and xtensa, which throw internal
> > compiler errors) and that one hasn't come up yet.
> >
> > could still be included indirectly though - I haven't checked for that
> > one specifically yet.
>
> If you are replacing mutex.h in include/linux/sched.h by mutex_types.h, I
> would suggest you add mutex.h to kernel/sched/sched.h to ensure this header
> file is included by the scheduler code.
It already does, via mutex_api.h...
On 12/18/23 22:37, Kent Overstreet wrote:
> On Mon, Dec 18, 2023 at 10:04:39PM -0500, Waiman Long wrote:
>> On 12/18/23 20:46, Kent Overstreet wrote:
>>> On Mon, Dec 18, 2023 at 11:53:08AM -0500, Waiman Long wrote:
>>>> On 12/15/23 22:26, Kent Overstreet wrote:
>>>>> -#include <linux/rtmutex.h>
>>>> Including rtmutex.h here means that mutex_types.h is no longer a simple
>>>> header for types only. So unless you also break out a rtmutex_types.h, it is
>>>> inconsistent.
>>> good observation, I'll have to leave it for the next round of cleanups
>>> though since the merge window is approaching and I'll have to redo all
>>> the testing.
>>>
>>>> Besides, the kernel/sched code does use mutex_lock/unlock calls quite
>>>> frequently. With this patch, mutex.h will not be directly included. I
>>>> suspect that it is indirectly included via other header files. This may be
>>>> an issue with some configurations.
>>> I've now put it through randconfig testing on every arch that debian
>>> includes a compiler for (excluding sh and xtensa, which throw internal
>>> compiler errors) and that one hasn't come up yet.
>>>
>>> could still be included indirectly though - I haven't checked for that
>>> one specifically yet.
>> If you are replacing mutex.h in include/linux/sched.h by mutex_types.h, I
>> would suggest you add mutex.h to kernel/sched/sched.h to ensure this header
>> file is included by the scheduler code.
> It already does, via mutex_api.h...
You are right. I am not aware that there is a mutex_api.h header file
which is just an alias of mutex.h.
Cheers,
Longman
@@ -20,6 +20,7 @@
#include <linux/osq_lock.h>
#include <linux/debug_locks.h>
#include <linux/cleanup.h>
+#include <linux/mutex_types.h>
#ifdef CONFIG_DEBUG_LOCK_ALLOC
# define __DEP_MAP_MUTEX_INITIALIZER(lockname) \
@@ -33,49 +34,6 @@
#ifndef CONFIG_PREEMPT_RT
-/*
- * Simple, straightforward mutexes with strict semantics:
- *
- * - only one task can hold the mutex at a time
- * - only the owner can unlock the mutex
- * - multiple unlocks are not permitted
- * - recursive locking is not permitted
- * - a mutex object must be initialized via the API
- * - a mutex object must not be initialized via memset or copying
- * - task may not exit with mutex held
- * - memory areas where held locks reside must not be freed
- * - held mutexes must not be reinitialized
- * - mutexes may not be used in hardware or software interrupt
- * contexts such as tasklets and timers
- *
- * These semantics are fully enforced when DEBUG_MUTEXES is
- * enabled. Furthermore, besides enforcing the above rules, the mutex
- * debugging code also implements a number of additional features
- * that make lock debugging easier and faster:
- *
- * - uses symbolic names of mutexes, whenever they are printed in debug output
- * - point-of-acquire tracking, symbolic lookup of function names
- * - list of all locks held in the system, printout of them
- * - owner tracking
- * - detects self-recursing locks and prints out all relevant info
- * - detects multi-task circular deadlocks and prints out all affected
- * locks and tasks (and only those tasks)
- */
-struct mutex {
- atomic_long_t owner;
- raw_spinlock_t wait_lock;
-#ifdef CONFIG_MUTEX_SPIN_ON_OWNER
- struct optimistic_spin_queue osq; /* Spinner MCS lock */
-#endif
- struct list_head wait_list;
-#ifdef CONFIG_DEBUG_MUTEXES
- void *magic;
-#endif
-#ifdef CONFIG_DEBUG_LOCK_ALLOC
- struct lockdep_map dep_map;
-#endif
-};
-
#ifdef CONFIG_DEBUG_MUTEXES
#define __DEBUG_MUTEX_INITIALIZER(lockname) \
@@ -131,14 +89,6 @@ extern bool mutex_is_locked(struct mutex *lock);
/*
* Preempt-RT variant based on rtmutexes.
*/
-#include <linux/rtmutex.h>
-
-struct mutex {
- struct rt_mutex_base rtmutex;
-#ifdef CONFIG_DEBUG_LOCK_ALLOC
- struct lockdep_map dep_map;
-#endif
-};
#define __MUTEX_INITIALIZER(mutexname) \
{ \
new file mode 100644
@@ -0,0 +1,71 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __LINUX_MUTEX_TYPES_H
+#define __LINUX_MUTEX_TYPES_H
+
+#include <linux/atomic.h>
+#include <linux/lockdep_types.h>
+#include <linux/osq_lock.h>
+#include <linux/spinlock_types.h>
+#include <linux/types.h>
+
+#ifndef CONFIG_PREEMPT_RT
+
+/*
+ * Simple, straightforward mutexes with strict semantics:
+ *
+ * - only one task can hold the mutex at a time
+ * - only the owner can unlock the mutex
+ * - multiple unlocks are not permitted
+ * - recursive locking is not permitted
+ * - a mutex object must be initialized via the API
+ * - a mutex object must not be initialized via memset or copying
+ * - task may not exit with mutex held
+ * - memory areas where held locks reside must not be freed
+ * - held mutexes must not be reinitialized
+ * - mutexes may not be used in hardware or software interrupt
+ * contexts such as tasklets and timers
+ *
+ * These semantics are fully enforced when DEBUG_MUTEXES is
+ * enabled. Furthermore, besides enforcing the above rules, the mutex
+ * debugging code also implements a number of additional features
+ * that make lock debugging easier and faster:
+ *
+ * - uses symbolic names of mutexes, whenever they are printed in debug output
+ * - point-of-acquire tracking, symbolic lookup of function names
+ * - list of all locks held in the system, printout of them
+ * - owner tracking
+ * - detects self-recursing locks and prints out all relevant info
+ * - detects multi-task circular deadlocks and prints out all affected
+ * locks and tasks (and only those tasks)
+ */
+struct mutex {
+ atomic_long_t owner;
+ raw_spinlock_t wait_lock;
+#ifdef CONFIG_MUTEX_SPIN_ON_OWNER
+ struct optimistic_spin_queue osq; /* Spinner MCS lock */
+#endif
+ struct list_head wait_list;
+#ifdef CONFIG_DEBUG_MUTEXES
+ void *magic;
+#endif
+#ifdef CONFIG_DEBUG_LOCK_ALLOC
+ struct lockdep_map dep_map;
+#endif
+};
+
+#else /* !CONFIG_PREEMPT_RT */
+/*
+ * Preempt-RT variant based on rtmutexes.
+ */
+#include <linux/rtmutex.h>
+
+struct mutex {
+ struct rt_mutex_base rtmutex;
+#ifdef CONFIG_DEBUG_LOCK_ALLOC
+ struct lockdep_map dep_map;
+#endif
+};
+
+#endif /* CONFIG_PREEMPT_RT */
+
+#endif /* __LINUX_MUTEX_TYPES_H */
@@ -15,7 +15,7 @@
#include <linux/sem.h>
#include <linux/shm.h>
#include <linux/kmsan_types.h>
-#include <linux/mutex.h>
+#include <linux/mutex_types.h>
#include <linux/plist.h>
#include <linux/hrtimer_types.h>
#include <linux/irqflags.h>