From: Bart Van Assche <bvanassche@acm.org>
To: peterz@infradead.org
Cc: mingo@redhat.com, tj@kernel.org, longman@redhat.com,
johannes.berg@intel.com, linux-kernel@vger.kernel.org,
Bart Van Assche <bvanassche@acm.org>
Subject: [PATCH v5 00/15] locking/lockdep: Add support for dynamic keys
Date: Mon, 17 Dec 2018 13:29:47 -0800 [thread overview]
Message-ID: <20181217213002.73776-1-bvanassche@acm.org> (raw)
Hi Peter and Ingo,
A known shortcoming of the current lockdep implementation is that it requires
lock keys to be allocated statically. This forces certain unrelated
synchronization objects to share keys and this key sharing can cause false
positive deadlock reports. This patch series adds support for dynamic keys in
the lockdep code and eliminates a class of false positive reports from the
workqueue implementation.
The changes compared to v4 are:
- Introduced the function lockdep_set_selftest_task() to fix a build failure
for CONFIG_LOCKDEP=n.
- Fixed a use-after-free issue in is_dynamic_key() by adding the following
code in that function: if (!debug_locks) return true;
- Changed if (WARN_ON_ONCE(!pf)) into if (!pf) to avoid that the new lockdep
implementation triggers more kernel warnings than the current implementation.
This keeps the build happy when doing regression tests.
- Added a synchronize_rcu() call at the end of lockdep_unregister_key() to
avoid a use-after-free.
The changes compared to v3 are:
- Rework the code that frees objects that are no longer used such that it
is now guaranteed that a grace period elapses between last use and freeing.
- The lockdep self tests pass again.
- Avoid that the patch that removes all matching lock order entries can
cause list corruption. Note: the change in this patch to realize that
is removed again by a later patch. In other words, this change is only
necessary to make the series bisectable.
- Rebased this patch series on top of the tip/locking/core branch.
The changes compared to v2 are:
- Made sure that all schedule_free_zapped_classes() calls are protected
with the graph lock.
- When removing a lock class, only recalculate lock chains that have been
modified.
- Combine a list_del() and list_add_tail() call into a list_move_tail()
call in register_lock_class().
- Use an RCU read lock instead of the graph lock inside is_dynamic_key().
The changes compared to v1 are:
- Addressed Peter's review comments: remove the list_head that I had added
to struct lock_list again, replaced all_list_entries and free_list_entries
by two bitmaps, use call_rcu() to free lockdep objects, add a BUILD_BUG_ON()
that compares the size of struct lock_class_key and raw_spin_lock_t.
- Addressed the "unknown symbol" errors reported by the build bot by adding a
few #ifdef / #endif directives. Addressed the 32-bit warnings by using %d
instead of %ld for array indices and by casting the array indices to
unsigned int.
- Removed several WARN_ON_ONCE(!class->hash_entry.pprev) statements since
these duplicate the code in check_data_structures().
- Left out the patch that causes lockdep to complain if no name has been
assigned to a lock object. That patch namely causes the build bot to
complain about certain lock objects but I have not yet had the time to
figure out the identity of these lock objects.
Bart.
Bart Van Assche (15):
locking/lockdep: Fix required memory size reported if
CONFIG_PROVE_LOCKING=n
locking/lockdep: Make zap_class() remove all matching lock order
entries
locking/lockdep: Reorder struct lock_class members
locking/lockdep: Initialize the locks_before and locks_after lists
earlier
locking/lockdep: Split lockdep_free_key_range() and
lockdep_reset_lock()
locking/lockdep: Make it easy to detect whether or not inside a
selftest
locking/lockdep: Free lock classes that are no longer in use
locking/lockdep: Reuse list entries that are no longer in use
locking/lockdep: Introduce lockdep_next_lockchain() and
lock_chain_count()
locking/lockdep: Reuse lock chains that have been freed
locking/lockdep: Check data structure consistency
locking/lockdep: Verify whether lock objects are small enough to be
used as class keys
locking/lockdep: Add support for dynamic keys
kernel/workqueue: Use dynamic lockdep keys for workqueues
lockdep tests: Test dynamic key registration
include/linux/lockdep.h | 42 +-
include/linux/workqueue.h | 28 +-
kernel/locking/lockdep.c | 913 +++++++++++++++---
kernel/locking/lockdep_internals.h | 3 +-
kernel/locking/lockdep_proc.c | 12 +-
kernel/workqueue.c | 60 +-
lib/locking-selftest.c | 2 +
tools/lib/lockdep/include/liblockdep/common.h | 2 +
tools/lib/lockdep/include/liblockdep/mutex.h | 11 +-
tools/lib/lockdep/tests/ABBA.c | 9 +
10 files changed, 913 insertions(+), 169 deletions(-)
--
2.20.0.405.gbc1bbc6f85-goog
next reply other threads:[~2018-12-17 21:31 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-17 21:29 Bart Van Assche [this message]
2018-12-17 21:29 ` [PATCH v5 01/15] locking/lockdep: Fix required memory size reported if CONFIG_PROVE_LOCKING=n Bart Van Assche
2018-12-17 21:29 ` [PATCH v5 02/15] locking/lockdep: Make zap_class() remove all matching lock order entries Bart Van Assche
2018-12-17 21:29 ` [PATCH v5 03/15] locking/lockdep: Reorder struct lock_class members Bart Van Assche
2018-12-17 21:29 ` [PATCH v5 04/15] locking/lockdep: Initialize the locks_before and locks_after lists earlier Bart Van Assche
2018-12-17 21:29 ` [PATCH v5 05/15] locking/lockdep: Split lockdep_free_key_range() and lockdep_reset_lock() Bart Van Assche
2018-12-17 21:29 ` [PATCH v5 06/15] locking/lockdep: Make it easy to detect whether or not inside a selftest Bart Van Assche
2018-12-17 21:29 ` [PATCH v5 07/15] locking/lockdep: Free lock classes that are no longer in use Bart Van Assche
2019-01-10 15:20 ` Peter Zijlstra
2019-01-10 15:45 ` Peter Zijlstra
2019-01-10 15:24 ` Peter Zijlstra
2019-01-10 18:51 ` Bart Van Assche
2019-01-10 19:44 ` Peter Zijlstra
2019-01-10 21:56 ` Bart Van Assche
2019-01-11 8:35 ` Peter Zijlstra
2019-02-13 0:42 ` Bart Van Assche
2019-01-10 15:28 ` Peter Zijlstra
2019-01-10 19:31 ` Bart Van Assche
2019-01-10 19:47 ` Peter Zijlstra
2018-12-17 21:29 ` [PATCH v5 08/15] locking/lockdep: Reuse list entries " Bart Van Assche
2018-12-17 21:29 ` [PATCH v5 09/15] locking/lockdep: Introduce lockdep_next_lockchain() and lock_chain_count() Bart Van Assche
2018-12-17 21:29 ` [PATCH v5 10/15] locking/lockdep: Reuse lock chains that have been freed Bart Van Assche
2018-12-17 21:29 ` [PATCH v5 11/15] locking/lockdep: Check data structure consistency Bart Van Assche
2019-01-10 15:51 ` Peter Zijlstra
2019-01-10 15:55 ` Peter Zijlstra
2018-12-17 21:29 ` [PATCH v5 12/15] locking/lockdep: Verify whether lock objects are small enough to be used as class keys Bart Van Assche
2018-12-17 21:30 ` [PATCH v5 13/15] locking/lockdep: Add support for dynamic keys Bart Van Assche
2018-12-17 21:30 ` [PATCH v5 14/15] kernel/workqueue: Use dynamic lockdep keys for workqueues Bart Van Assche
2018-12-17 21:30 ` [PATCH v5 15/15] lockdep tests: Test dynamic key registration Bart Van Assche
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181217213002.73776-1-bvanassche@acm.org \
--to=bvanassche@acm.org \
--cc=johannes.berg@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=longman@redhat.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).