License cleanup: add SPDX GPL-2.0 license identifier to files with no license
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.
By default all files without license information are under the default
license of the kernel, which is GPL version 2.
Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.
This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.
How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,
Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.
The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.
The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.
Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if <5
lines).
All documentation files were explicitly excluded.
The following heuristics were used to determine which SPDX license
identifiers to apply.
- when both scanners couldn't find any license traces, file was
considered to have no license information in it, and the top level
COPYING file license applied.
For non */uapi/* files that summary was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 11139
and resulted in the first patch in this series.
If that file was a */uapi/* path one, it was "GPL-2.0 WITH
Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 WITH Linux-syscall-note 930
and resulted in the second patch in this series.
- if a file had some form of licensing information in it, and was one
of the */uapi/* ones, it was denoted with the Linux-syscall-note if
any GPL family license was found in the file or had no licensing in
it (per prior point). Results summary:
SPDX license identifier # files
---------------------------------------------------|------
GPL-2.0 WITH Linux-syscall-note 270
GPL-2.0+ WITH Linux-syscall-note 169
((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21
((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17
LGPL-2.1+ WITH Linux-syscall-note 15
GPL-1.0+ WITH Linux-syscall-note 14
((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5
LGPL-2.0+ WITH Linux-syscall-note 4
LGPL-2.1 WITH Linux-syscall-note 3
((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3
((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1
and that resulted in the third patch in this series.
- when the two scanners agreed on the detected license(s), that became
the concluded license(s).
- when there was disagreement between the two scanners (one detected a
license but the other didn't, or they both detected different
licenses) a manual inspection of the file occurred.
- In most cases a manual inspection of the information in the file
resulted in a clear resolution of the license that should apply (and
which scanner probably needed to revisit its heuristics).
- When it was not immediately clear, the license identifier was
confirmed with lawyers working with the Linux Foundation.
- If there was any question as to the appropriate license identifier,
the file was flagged for further research and to be revisited later
in time.
In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.
Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights. The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.
Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.
In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.
Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
- a full scancode scan run, collecting the matched texts, detected
license ids and scores
- reviewing anything where there was a license detected (about 500+
files) to ensure that the applied SPDX license was correct
- reviewing anything where there was no detection but the patch license
was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
SPDX license was correct
This produced a worksheet with 20 files needing minor correction. This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.
These .csv files were then reviewed by Greg. Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected. This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.) Finally Greg ran the script using the .csv files to
generate the patches.
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-01 17:07:57 +03:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0 */
|
2006-01-10 02:59:19 +03:00
|
|
|
/*
|
|
|
|
* Mutexes: blocking mutual exclusion locks
|
|
|
|
*
|
|
|
|
* started by Ingo Molnar:
|
|
|
|
*
|
|
|
|
* Copyright (C) 2004, 2005, 2006 Red Hat, Inc., Ingo Molnar <mingo@redhat.com>
|
|
|
|
*
|
|
|
|
* This file contains the main data structure and API definitions.
|
|
|
|
*/
|
|
|
|
#ifndef __LINUX_MUTEX_H
|
|
|
|
#define __LINUX_MUTEX_H
|
|
|
|
|
2013-06-24 12:30:04 +04:00
|
|
|
#include <asm/current.h>
|
2006-01-10 02:59:19 +03:00
|
|
|
#include <linux/list.h>
|
|
|
|
#include <linux/spinlock_types.h>
|
2006-07-03 11:24:55 +04:00
|
|
|
#include <linux/lockdep.h>
|
2011-07-27 03:09:06 +04:00
|
|
|
#include <linux/atomic.h>
|
2013-09-28 13:23:59 +04:00
|
|
|
#include <asm/processor.h>
|
2014-07-14 21:27:49 +04:00
|
|
|
#include <linux/osq_lock.h>
|
2016-08-23 14:36:04 +03:00
|
|
|
#include <linux/debug_locks.h>
|
2006-01-10 02:59:19 +03:00
|
|
|
|
2016-12-21 21:46:34 +03:00
|
|
|
struct ww_acquire_ctx;
|
|
|
|
|
2006-01-10 02:59:19 +03:00
|
|
|
/*
|
|
|
|
* 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
|
2007-10-17 10:29:41 +04:00
|
|
|
* - mutexes may not be used in hardware or software interrupt
|
|
|
|
* contexts such as tasklets and timers
|
2006-01-10 02:59:19 +03:00
|
|
|
*
|
|
|
|
* 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 {
|
2016-08-23 14:36:04 +03:00
|
|
|
atomic_long_t owner;
|
2006-01-10 02:59:19 +03:00
|
|
|
spinlock_t wait_lock;
|
mutex: Queue mutex spinners with MCS lock to reduce cacheline contention
The current mutex spinning code (with MUTEX_SPIN_ON_OWNER option
turned on) allow multiple tasks to spin on a single mutex
concurrently. A potential problem with the current approach is
that when the mutex becomes available, all the spinning tasks
will try to acquire the mutex more or less simultaneously. As a
result, there will be a lot of cacheline bouncing especially on
systems with a large number of CPUs.
This patch tries to reduce this kind of contention by putting
the mutex spinners into a queue so that only the first one in
the queue will try to acquire the mutex. This will reduce
contention and allow all the tasks to move forward faster.
The queuing of mutex spinners is done using an MCS lock based
implementation which will further reduce contention on the mutex
cacheline than a similar ticket spinlock based implementation.
This patch will add a new field into the mutex data structure
for holding the MCS lock. This expands the mutex size by 8 bytes
for 64-bit system and 4 bytes for 32-bit system. This overhead
will be avoid if the MUTEX_SPIN_ON_OWNER option is turned off.
The following table shows the jobs per minute (JPM) scalability
data on an 8-node 80-core Westmere box with a 3.7.10 kernel. The
numactl command is used to restrict the running of the fserver
workloads to 1/2/4/8 nodes with hyperthreading off.
+-----------------+-----------+-----------+-------------+----------+
| Configuration | Mean JPM | Mean JPM | Mean JPM | % Change |
| | w/o patch | patch 1 | patches 1&2 | 1->1&2 |
+-----------------+------------------------------------------------+
| | User Range 1100 - 2000 |
+-----------------+------------------------------------------------+
| 8 nodes, HT off | 227972 | 227237 | 305043 | +34.2% |
| 4 nodes, HT off | 393503 | 381558 | 394650 | +3.4% |
| 2 nodes, HT off | 334957 | 325240 | 338853 | +4.2% |
| 1 node , HT off | 198141 | 197972 | 198075 | +0.1% |
+-----------------+------------------------------------------------+
| | User Range 200 - 1000 |
+-----------------+------------------------------------------------+
| 8 nodes, HT off | 282325 | 312870 | 332185 | +6.2% |
| 4 nodes, HT off | 390698 | 378279 | 393419 | +4.0% |
| 2 nodes, HT off | 336986 | 326543 | 340260 | +4.2% |
| 1 node , HT off | 197588 | 197622 | 197582 | 0.0% |
+-----------------+-----------+-----------+-------------+----------+
At low user range 10-100, the JPM differences were within +/-1%.
So they are not that interesting.
The fserver workload uses mutex spinning extensively. With just
the mutex change in the first patch, there is no noticeable
change in performance. Rather, there is a slight drop in
performance. This mutex spinning patch more than recovers the
lost performance and show a significant increase of +30% at high
user load with the full 8 nodes. Similar improvements were also
seen in a 3.8 kernel.
The table below shows the %time spent by different kernel
functions as reported by perf when running the fserver workload
at 1500 users with all 8 nodes.
+-----------------------+-----------+---------+-------------+
| Function | % time | % time | % time |
| | w/o patch | patch 1 | patches 1&2 |
+-----------------------+-----------+---------+-------------+
| __read_lock_failed | 34.96% | 34.91% | 29.14% |
| __write_lock_failed | 10.14% | 10.68% | 7.51% |
| mutex_spin_on_owner | 3.62% | 3.42% | 2.33% |
| mspin_lock | N/A | N/A | 9.90% |
| __mutex_lock_slowpath | 1.46% | 0.81% | 0.14% |
| _raw_spin_lock | 2.25% | 2.50% | 1.10% |
+-----------------------+-----------+---------+-------------+
The fserver workload for an 8-node system is dominated by the
contention in the read/write lock. Mutex contention also plays a
role. With the first patch only, mutex contention is down (as
shown by the __mutex_lock_slowpath figure) which help a little
bit. We saw only a few percents improvement with that.
By applying patch 2 as well, the single mutex_spin_on_owner
figure is now split out into an additional mspin_lock figure.
The time increases from 3.42% to 11.23%. It shows a great
reduction in contention among the spinners leading to a 30%
improvement. The time ratio 9.9/2.33=4.3 indicates that there
are on average 4+ spinners waiting in the spin_lock loop for
each spinner in the mutex_spin_on_owner loop. Contention in
other locking functions also go down by quite a lot.
The table below shows the performance change of both patches 1 &
2 over patch 1 alone in other AIM7 workloads (at 8 nodes,
hyperthreading off).
+--------------+---------------+----------------+-----------------+
| Workload | mean % change | mean % change | mean % change |
| | 10-100 users | 200-1000 users | 1100-2000 users |
+--------------+---------------+----------------+-----------------+
| alltests | 0.0% | -0.8% | +0.6% |
| five_sec | -0.3% | +0.8% | +0.8% |
| high_systime | +0.4% | +2.4% | +2.1% |
| new_fserver | +0.1% | +14.1% | +34.2% |
| shared | -0.5% | -0.3% | -0.4% |
| short | -1.7% | -9.8% | -8.3% |
+--------------+---------------+----------------+-----------------+
The short workload is the only one that shows a decline in
performance probably due to the spinner locking and queuing
overhead.
Signed-off-by: Waiman Long <Waiman.Long@hp.com>
Reviewed-by: Davidlohr Bueso <davidlohr.bueso@hp.com>
Acked-by: Rik van Riel <riel@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Chandramouleeswaran Aswin <aswin@hp.com>
Cc: Norton Scott J <scott.norton@hp.com>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: David Howells <dhowells@redhat.com>
Cc: Dave Jones <davej@redhat.com>
Cc: Clark Williams <williams@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1366226594-5506-4-git-send-email-Waiman.Long@hp.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-04-17 23:23:13 +04:00
|
|
|
#ifdef CONFIG_MUTEX_SPIN_ON_OWNER
|
2014-07-14 21:27:49 +04:00
|
|
|
struct optimistic_spin_queue osq; /* Spinner MCS lock */
|
mutex: Queue mutex spinners with MCS lock to reduce cacheline contention
The current mutex spinning code (with MUTEX_SPIN_ON_OWNER option
turned on) allow multiple tasks to spin on a single mutex
concurrently. A potential problem with the current approach is
that when the mutex becomes available, all the spinning tasks
will try to acquire the mutex more or less simultaneously. As a
result, there will be a lot of cacheline bouncing especially on
systems with a large number of CPUs.
This patch tries to reduce this kind of contention by putting
the mutex spinners into a queue so that only the first one in
the queue will try to acquire the mutex. This will reduce
contention and allow all the tasks to move forward faster.
The queuing of mutex spinners is done using an MCS lock based
implementation which will further reduce contention on the mutex
cacheline than a similar ticket spinlock based implementation.
This patch will add a new field into the mutex data structure
for holding the MCS lock. This expands the mutex size by 8 bytes
for 64-bit system and 4 bytes for 32-bit system. This overhead
will be avoid if the MUTEX_SPIN_ON_OWNER option is turned off.
The following table shows the jobs per minute (JPM) scalability
data on an 8-node 80-core Westmere box with a 3.7.10 kernel. The
numactl command is used to restrict the running of the fserver
workloads to 1/2/4/8 nodes with hyperthreading off.
+-----------------+-----------+-----------+-------------+----------+
| Configuration | Mean JPM | Mean JPM | Mean JPM | % Change |
| | w/o patch | patch 1 | patches 1&2 | 1->1&2 |
+-----------------+------------------------------------------------+
| | User Range 1100 - 2000 |
+-----------------+------------------------------------------------+
| 8 nodes, HT off | 227972 | 227237 | 305043 | +34.2% |
| 4 nodes, HT off | 393503 | 381558 | 394650 | +3.4% |
| 2 nodes, HT off | 334957 | 325240 | 338853 | +4.2% |
| 1 node , HT off | 198141 | 197972 | 198075 | +0.1% |
+-----------------+------------------------------------------------+
| | User Range 200 - 1000 |
+-----------------+------------------------------------------------+
| 8 nodes, HT off | 282325 | 312870 | 332185 | +6.2% |
| 4 nodes, HT off | 390698 | 378279 | 393419 | +4.0% |
| 2 nodes, HT off | 336986 | 326543 | 340260 | +4.2% |
| 1 node , HT off | 197588 | 197622 | 197582 | 0.0% |
+-----------------+-----------+-----------+-------------+----------+
At low user range 10-100, the JPM differences were within +/-1%.
So they are not that interesting.
The fserver workload uses mutex spinning extensively. With just
the mutex change in the first patch, there is no noticeable
change in performance. Rather, there is a slight drop in
performance. This mutex spinning patch more than recovers the
lost performance and show a significant increase of +30% at high
user load with the full 8 nodes. Similar improvements were also
seen in a 3.8 kernel.
The table below shows the %time spent by different kernel
functions as reported by perf when running the fserver workload
at 1500 users with all 8 nodes.
+-----------------------+-----------+---------+-------------+
| Function | % time | % time | % time |
| | w/o patch | patch 1 | patches 1&2 |
+-----------------------+-----------+---------+-------------+
| __read_lock_failed | 34.96% | 34.91% | 29.14% |
| __write_lock_failed | 10.14% | 10.68% | 7.51% |
| mutex_spin_on_owner | 3.62% | 3.42% | 2.33% |
| mspin_lock | N/A | N/A | 9.90% |
| __mutex_lock_slowpath | 1.46% | 0.81% | 0.14% |
| _raw_spin_lock | 2.25% | 2.50% | 1.10% |
+-----------------------+-----------+---------+-------------+
The fserver workload for an 8-node system is dominated by the
contention in the read/write lock. Mutex contention also plays a
role. With the first patch only, mutex contention is down (as
shown by the __mutex_lock_slowpath figure) which help a little
bit. We saw only a few percents improvement with that.
By applying patch 2 as well, the single mutex_spin_on_owner
figure is now split out into an additional mspin_lock figure.
The time increases from 3.42% to 11.23%. It shows a great
reduction in contention among the spinners leading to a 30%
improvement. The time ratio 9.9/2.33=4.3 indicates that there
are on average 4+ spinners waiting in the spin_lock loop for
each spinner in the mutex_spin_on_owner loop. Contention in
other locking functions also go down by quite a lot.
The table below shows the performance change of both patches 1 &
2 over patch 1 alone in other AIM7 workloads (at 8 nodes,
hyperthreading off).
+--------------+---------------+----------------+-----------------+
| Workload | mean % change | mean % change | mean % change |
| | 10-100 users | 200-1000 users | 1100-2000 users |
+--------------+---------------+----------------+-----------------+
| alltests | 0.0% | -0.8% | +0.6% |
| five_sec | -0.3% | +0.8% | +0.8% |
| high_systime | +0.4% | +2.4% | +2.1% |
| new_fserver | +0.1% | +14.1% | +34.2% |
| shared | -0.5% | -0.3% | -0.4% |
| short | -1.7% | -9.8% | -8.3% |
+--------------+---------------+----------------+-----------------+
The short workload is the only one that shows a decline in
performance probably due to the spinner locking and queuing
overhead.
Signed-off-by: Waiman Long <Waiman.Long@hp.com>
Reviewed-by: Davidlohr Bueso <davidlohr.bueso@hp.com>
Acked-by: Rik van Riel <riel@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Chandramouleeswaran Aswin <aswin@hp.com>
Cc: Norton Scott J <scott.norton@hp.com>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: David Howells <dhowells@redhat.com>
Cc: Dave Jones <davej@redhat.com>
Cc: Clark Williams <williams@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1366226594-5506-4-git-send-email-Waiman.Long@hp.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-04-17 23:23:13 +04:00
|
|
|
#endif
|
2016-08-23 14:36:04 +03:00
|
|
|
struct list_head wait_list;
|
2009-01-12 16:01:47 +03:00
|
|
|
#ifdef CONFIG_DEBUG_MUTEXES
|
2006-01-10 02:59:19 +03:00
|
|
|
void *magic;
|
|
|
|
#endif
|
2006-07-03 11:24:55 +04:00
|
|
|
#ifdef CONFIG_DEBUG_LOCK_ALLOC
|
|
|
|
struct lockdep_map dep_map;
|
|
|
|
#endif
|
2006-01-10 02:59:19 +03:00
|
|
|
};
|
|
|
|
|
2019-08-08 09:47:14 +03:00
|
|
|
/*
|
|
|
|
* This is the control structure for tasks blocked on mutex,
|
|
|
|
* which resides on the blocked task's kernel stack:
|
|
|
|
*/
|
|
|
|
struct mutex_waiter {
|
|
|
|
struct list_head list;
|
|
|
|
struct task_struct *task;
|
|
|
|
struct ww_acquire_ctx *ww_ctx;
|
|
|
|
#ifdef CONFIG_DEBUG_MUTEXES
|
|
|
|
void *magic;
|
|
|
|
#endif
|
|
|
|
};
|
|
|
|
|
2006-01-10 02:59:19 +03:00
|
|
|
#ifdef CONFIG_DEBUG_MUTEXES
|
2016-08-23 14:36:04 +03:00
|
|
|
|
|
|
|
#define __DEBUG_MUTEX_INITIALIZER(lockname) \
|
|
|
|
, .magic = &lockname
|
|
|
|
|
|
|
|
extern void mutex_destroy(struct mutex *lock);
|
|
|
|
|
2006-01-10 02:59:19 +03:00
|
|
|
#else
|
2016-08-23 14:36:04 +03:00
|
|
|
|
2006-01-10 02:59:19 +03:00
|
|
|
# define __DEBUG_MUTEX_INITIALIZER(lockname)
|
2016-08-23 14:36:04 +03:00
|
|
|
|
|
|
|
static inline void mutex_destroy(struct mutex *lock) {}
|
|
|
|
|
|
|
|
#endif
|
|
|
|
|
2010-09-03 02:48:16 +04:00
|
|
|
/**
|
|
|
|
* mutex_init - initialize the mutex
|
|
|
|
* @mutex: the mutex to be initialized
|
|
|
|
*
|
|
|
|
* Initialize the mutex to unlocked state.
|
|
|
|
*
|
|
|
|
* It is not allowed to initialize an already locked mutex.
|
|
|
|
*/
|
2016-08-23 14:36:04 +03:00
|
|
|
#define mutex_init(mutex) \
|
|
|
|
do { \
|
|
|
|
static struct lock_class_key __key; \
|
|
|
|
\
|
|
|
|
__mutex_init((mutex), #mutex, &__key); \
|
2006-07-03 11:24:55 +04:00
|
|
|
} while (0)
|
2006-01-10 02:59:19 +03:00
|
|
|
|
2006-07-03 11:24:55 +04:00
|
|
|
#ifdef CONFIG_DEBUG_LOCK_ALLOC
|
lockdep: Introduce wait-type checks
Extend lockdep to validate lock wait-type context.
The current wait-types are:
LD_WAIT_FREE, /* wait free, rcu etc.. */
LD_WAIT_SPIN, /* spin loops, raw_spinlock_t etc.. */
LD_WAIT_CONFIG, /* CONFIG_PREEMPT_LOCK, spinlock_t etc.. */
LD_WAIT_SLEEP, /* sleeping locks, mutex_t etc.. */
Where lockdep validates that the current lock (the one being acquired)
fits in the current wait-context (as generated by the held stack).
This ensures that there is no attempt to acquire mutexes while holding
spinlocks, to acquire spinlocks while holding raw_spinlocks and so on. In
other words, its a more fancy might_sleep().
Obviously RCU made the entire ordeal more complex than a simple single
value test because RCU can be acquired in (pretty much) any context and
while it presents a context to nested locks it is not the same as it
got acquired in.
Therefore its necessary to split the wait_type into two values, one
representing the acquire (outer) and one representing the nested context
(inner). For most 'normal' locks these two are the same.
[ To make static initialization easier we have the rule that:
.outer == INV means .outer == .inner; because INV == 0. ]
It further means that its required to find the minimal .inner of the held
stack to compare against the outer of the new lock; because while 'normal'
RCU presents a CONFIG type to nested locks, if it is taken while already
holding a SPIN type it obviously doesn't relax the rules.
Below is an example output generated by the trivial test code:
raw_spin_lock(&foo);
spin_lock(&bar);
spin_unlock(&bar);
raw_spin_unlock(&foo);
[ BUG: Invalid wait context ]
-----------------------------
swapper/0/1 is trying to lock:
ffffc90000013f20 (&bar){....}-{3:3}, at: kernel_init+0xdb/0x187
other info that might help us debug this:
1 lock held by swapper/0/1:
#0: ffffc90000013ee0 (&foo){+.+.}-{2:2}, at: kernel_init+0xd1/0x187
The way to read it is to look at the new -{n,m} part in the lock
description; -{3:3} for the attempted lock, and try and match that up to
the held locks, which in this case is the one: -{2,2}.
This tells that the acquiring lock requires a more relaxed environment than
presented by the lock stack.
Currently only the normal locks and RCU are converted, the rest of the
lockdep users defaults to .inner = INV which is ignored. More conversions
can be done when desired.
The check for spinlock_t nesting is not enabled by default. It's a separate
config option for now as there are known problems which are currently
addressed. The config option allows to identify these problems and to
verify that the solutions found are indeed solving them.
The config switch will be removed and the checks will permanently enabled
once the vast majority of issues has been addressed.
[ bigeasy: Move LD_WAIT_FREE,… out of CONFIG_LOCKDEP to avoid compile
failure with CONFIG_DEBUG_SPINLOCK + !CONFIG_LOCKDEP]
[ tglx: Add the config option ]
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20200321113242.427089655@linutronix.de
2020-03-21 14:26:01 +03:00
|
|
|
# define __DEP_MAP_MUTEX_INITIALIZER(lockname) \
|
|
|
|
, .dep_map = { \
|
|
|
|
.name = #lockname, \
|
|
|
|
.wait_type_inner = LD_WAIT_SLEEP, \
|
|
|
|
}
|
2006-07-03 11:24:55 +04:00
|
|
|
#else
|
|
|
|
# define __DEP_MAP_MUTEX_INITIALIZER(lockname)
|
|
|
|
#endif
|
|
|
|
|
2006-01-10 02:59:19 +03:00
|
|
|
#define __MUTEX_INITIALIZER(lockname) \
|
2016-08-23 14:36:04 +03:00
|
|
|
{ .owner = ATOMIC_LONG_INIT(0) \
|
2006-12-07 07:37:22 +03:00
|
|
|
, .wait_lock = __SPIN_LOCK_UNLOCKED(lockname.wait_lock) \
|
2006-01-10 02:59:19 +03:00
|
|
|
, .wait_list = LIST_HEAD_INIT(lockname.wait_list) \
|
2006-07-03 11:24:55 +04:00
|
|
|
__DEBUG_MUTEX_INITIALIZER(lockname) \
|
|
|
|
__DEP_MAP_MUTEX_INITIALIZER(lockname) }
|
2006-01-10 02:59:19 +03:00
|
|
|
|
|
|
|
#define DEFINE_MUTEX(mutexname) \
|
|
|
|
struct mutex mutexname = __MUTEX_INITIALIZER(mutexname)
|
|
|
|
|
2006-07-03 11:24:55 +04:00
|
|
|
extern void __mutex_init(struct mutex *lock, const char *name,
|
|
|
|
struct lock_class_key *key);
|
2006-01-10 02:59:19 +03:00
|
|
|
|
2007-01-26 11:57:09 +03:00
|
|
|
/**
|
2006-01-10 02:59:19 +03:00
|
|
|
* mutex_is_locked - is the mutex locked
|
|
|
|
* @lock: the mutex to be queried
|
|
|
|
*
|
2018-02-07 02:41:35 +03:00
|
|
|
* Returns true if the mutex is locked, false if unlocked.
|
2006-01-10 02:59:19 +03:00
|
|
|
*/
|
2019-07-31 18:05:03 +03:00
|
|
|
extern bool mutex_is_locked(struct mutex *lock);
|
2006-01-10 02:59:19 +03:00
|
|
|
|
|
|
|
/*
|
2013-11-08 11:26:39 +04:00
|
|
|
* See kernel/locking/mutex.c for detailed documentation of these APIs.
|
2019-04-10 14:32:41 +03:00
|
|
|
* Also see Documentation/locking/mutex-design.rst.
|
2006-01-10 02:59:19 +03:00
|
|
|
*/
|
2006-07-03 11:24:55 +04:00
|
|
|
#ifdef CONFIG_DEBUG_LOCK_ALLOC
|
|
|
|
extern void mutex_lock_nested(struct mutex *lock, unsigned int subclass);
|
2011-05-25 04:12:03 +04:00
|
|
|
extern void _mutex_lock_nest_lock(struct mutex *lock, struct lockdep_map *nest_lock);
|
2013-06-24 12:30:04 +04:00
|
|
|
|
2007-05-09 13:33:39 +04:00
|
|
|
extern int __must_check mutex_lock_interruptible_nested(struct mutex *lock,
|
|
|
|
unsigned int subclass);
|
2007-12-07 01:37:59 +03:00
|
|
|
extern int __must_check mutex_lock_killable_nested(struct mutex *lock,
|
|
|
|
unsigned int subclass);
|
2016-10-28 19:58:11 +03:00
|
|
|
extern void mutex_lock_io_nested(struct mutex *lock, unsigned int subclass);
|
2007-10-12 00:11:12 +04:00
|
|
|
|
|
|
|
#define mutex_lock(lock) mutex_lock_nested(lock, 0)
|
|
|
|
#define mutex_lock_interruptible(lock) mutex_lock_interruptible_nested(lock, 0)
|
2007-12-07 01:37:59 +03:00
|
|
|
#define mutex_lock_killable(lock) mutex_lock_killable_nested(lock, 0)
|
2016-10-28 19:58:11 +03:00
|
|
|
#define mutex_lock_io(lock) mutex_lock_io_nested(lock, 0)
|
2011-05-25 04:12:03 +04:00
|
|
|
|
|
|
|
#define mutex_lock_nest_lock(lock, nest_lock) \
|
|
|
|
do { \
|
2013-06-24 12:30:04 +04:00
|
|
|
typecheck(struct lockdep_map *, &(nest_lock)->dep_map); \
|
2011-05-25 04:12:03 +04:00
|
|
|
_mutex_lock_nest_lock(lock, &(nest_lock)->dep_map); \
|
|
|
|
} while (0)
|
|
|
|
|
2006-07-03 11:24:55 +04:00
|
|
|
#else
|
2008-02-08 15:19:55 +03:00
|
|
|
extern void mutex_lock(struct mutex *lock);
|
|
|
|
extern int __must_check mutex_lock_interruptible(struct mutex *lock);
|
|
|
|
extern int __must_check mutex_lock_killable(struct mutex *lock);
|
2016-10-28 19:58:11 +03:00
|
|
|
extern void mutex_lock_io(struct mutex *lock);
|
2007-10-12 00:11:12 +04:00
|
|
|
|
2006-07-03 11:24:55 +04:00
|
|
|
# define mutex_lock_nested(lock, subclass) mutex_lock(lock)
|
2006-12-08 13:36:17 +03:00
|
|
|
# define mutex_lock_interruptible_nested(lock, subclass) mutex_lock_interruptible(lock)
|
2007-12-07 01:37:59 +03:00
|
|
|
# define mutex_lock_killable_nested(lock, subclass) mutex_lock_killable(lock)
|
2011-05-25 04:12:03 +04:00
|
|
|
# define mutex_lock_nest_lock(lock, nest_lock) mutex_lock(lock)
|
2017-01-14 19:11:36 +03:00
|
|
|
# define mutex_lock_io_nested(lock, subclass) mutex_lock(lock)
|
2006-07-03 11:24:55 +04:00
|
|
|
#endif
|
|
|
|
|
2006-01-10 02:59:19 +03:00
|
|
|
/*
|
|
|
|
* NOTE: mutex_trylock() follows the spin_trylock() convention,
|
|
|
|
* not the down_trylock() convention!
|
2008-10-30 00:24:09 +03:00
|
|
|
*
|
|
|
|
* Returns 1 if the mutex has been acquired successfully, and 0 on contention.
|
2006-01-10 02:59:19 +03:00
|
|
|
*/
|
2008-02-08 15:19:55 +03:00
|
|
|
extern int mutex_trylock(struct mutex *lock);
|
|
|
|
extern void mutex_unlock(struct mutex *lock);
|
2013-06-24 12:30:04 +04:00
|
|
|
|
2009-04-30 02:59:58 +04:00
|
|
|
extern int atomic_dec_and_mutex_lock(atomic_t *cnt, struct mutex *lock);
|
2009-03-23 20:22:09 +03:00
|
|
|
|
2016-10-07 18:43:51 +03:00
|
|
|
/*
|
|
|
|
* These values are chosen such that FAIL and SUCCESS match the
|
|
|
|
* values of the regular mutex_trylock().
|
|
|
|
*/
|
|
|
|
enum mutex_trylock_recursive_enum {
|
|
|
|
MUTEX_TRYLOCK_FAILED = 0,
|
|
|
|
MUTEX_TRYLOCK_SUCCESS = 1,
|
|
|
|
MUTEX_TRYLOCK_RECURSIVE,
|
|
|
|
};
|
|
|
|
|
|
|
|
/**
|
|
|
|
* mutex_trylock_recursive - trylock variant that allows recursive locking
|
|
|
|
* @lock: mutex to be locked
|
|
|
|
*
|
|
|
|
* This function should not be used, _ever_. It is purely for hysterical GEM
|
|
|
|
* raisins, and once those are gone this will be removed.
|
|
|
|
*
|
|
|
|
* Returns:
|
2017-05-11 16:17:45 +03:00
|
|
|
* - MUTEX_TRYLOCK_FAILED - trylock failed,
|
|
|
|
* - MUTEX_TRYLOCK_SUCCESS - lock acquired,
|
|
|
|
* - MUTEX_TRYLOCK_RECURSIVE - we already owned the lock.
|
2016-10-07 18:43:51 +03:00
|
|
|
*/
|
2019-07-31 18:05:03 +03:00
|
|
|
extern /* __deprecated */ __must_check enum mutex_trylock_recursive_enum
|
|
|
|
mutex_trylock_recursive(struct mutex *lock);
|
2016-10-07 18:43:51 +03:00
|
|
|
|
2014-01-22 03:36:00 +04:00
|
|
|
#endif /* __LINUX_MUTEX_H */
|