linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: tip-bot for Peter Zijlstra <tipbot@zytor.com>
To: linux-tip-commits@vger.kernel.org
Cc: byungchul.park@lge.com, mingo@kernel.org, tglx@linutronix.de,
	linux-kernel@vger.kernel.org, hpa@zytor.com,
	peterz@infradead.org, torvalds@linux-foundation.org
Subject: [tip:locking/core] locking/lockdep: Untangle xhlock history save/restore from task independence
Date: Tue, 29 Aug 2017 07:23:12 -0700	[thread overview]
Message-ID: <tip-f52be5708076b75a045ac52c6fef3fffb8300525@git.kernel.org> (raw)
In-Reply-To: <20170829085939.ggmb6xiohw67micb@hirez.programming.kicks-ass.net>

Commit-ID:  f52be5708076b75a045ac52c6fef3fffb8300525
Gitweb:     http://git.kernel.org/tip/f52be5708076b75a045ac52c6fef3fffb8300525
Author:     Peter Zijlstra <peterz@infradead.org>
AuthorDate: Tue, 29 Aug 2017 10:59:39 +0200
Committer:  Ingo Molnar <mingo@kernel.org>
CommitDate: Tue, 29 Aug 2017 15:14:38 +0200

locking/lockdep: Untangle xhlock history save/restore from task independence

Where XHLOCK_{SOFT,HARD} are save/restore points in the xhlocks[] to
ensure the temporal IRQ events don't interact with task state, the
XHLOCK_PROC is a fundament different beast that just happens to share
the interface.

The purpose of XHLOCK_PROC is to annotate independent execution inside
one task. For example workqueues, each work should appear to run in its
own 'pristine' 'task'.

Remove XHLOCK_PROC in favour of its own interface to avoid confusion.

Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Byungchul Park <byungchul.park@lge.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: boqun.feng@gmail.com
Cc: david@fromorbit.com
Cc: johannes@sipsolutions.net
Cc: kernel-team@lge.com
Cc: oleg@redhat.com
Cc: tj@kernel.org
Link: http://lkml.kernel.org/r/20170829085939.ggmb6xiohw67micb@hirez.programming.kicks-ass.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
 include/linux/irqflags.h |  4 +--
 include/linux/lockdep.h  |  7 +++--
 kernel/locking/lockdep.c | 79 +++++++++++++++++++++++-------------------------
 kernel/workqueue.c       |  9 +++---
 4 files changed, 48 insertions(+), 51 deletions(-)

diff --git a/include/linux/irqflags.h b/include/linux/irqflags.h
index 9bc050b..5fdd93b 100644
--- a/include/linux/irqflags.h
+++ b/include/linux/irqflags.h
@@ -26,7 +26,7 @@
 # define trace_hardirq_enter()			\
 do {						\
 	current->hardirq_context++;		\
-	crossrelease_hist_start(XHLOCK_HARD, 0);\
+	crossrelease_hist_start(XHLOCK_HARD);	\
 } while (0)
 # define trace_hardirq_exit()			\
 do {						\
@@ -36,7 +36,7 @@ do {						\
 # define lockdep_softirq_enter()		\
 do {						\
 	current->softirq_context++;		\
-	crossrelease_hist_start(XHLOCK_SOFT, 0);\
+	crossrelease_hist_start(XHLOCK_SOFT);	\
 } while (0)
 # define lockdep_softirq_exit()			\
 do {						\
diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
index 78bb713..bfa8e0b 100644
--- a/include/linux/lockdep.h
+++ b/include/linux/lockdep.h
@@ -551,7 +551,6 @@ struct pin_cookie { };
 enum xhlock_context_t {
 	XHLOCK_HARD,
 	XHLOCK_SOFT,
-	XHLOCK_PROC,
 	XHLOCK_CTX_NR,
 };
 
@@ -580,8 +579,9 @@ extern void lock_commit_crosslock(struct lockdep_map *lock);
 #define STATIC_LOCKDEP_MAP_INIT(_name, _key) \
 	{ .name = (_name), .key = (void *)(_key), .cross = 0, }
 
-extern void crossrelease_hist_start(enum xhlock_context_t c, bool force);
+extern void crossrelease_hist_start(enum xhlock_context_t c);
 extern void crossrelease_hist_end(enum xhlock_context_t c);
+extern void lockdep_invariant_state(bool force);
 extern void lockdep_init_task(struct task_struct *task);
 extern void lockdep_free_task(struct task_struct *task);
 #else /* !CROSSRELEASE */
@@ -593,8 +593,9 @@ extern void lockdep_free_task(struct task_struct *task);
 #define STATIC_LOCKDEP_MAP_INIT(_name, _key) \
 	{ .name = (_name), .key = (void *)(_key), }
 
-static inline void crossrelease_hist_start(enum xhlock_context_t c, bool force) {}
+static inline void crossrelease_hist_start(enum xhlock_context_t c) {}
 static inline void crossrelease_hist_end(enum xhlock_context_t c) {}
+static inline void lockdep_invariant_state(bool force) {}
 static inline void lockdep_init_task(struct task_struct *task) {}
 static inline void lockdep_free_task(struct task_struct *task) {}
 #endif /* CROSSRELEASE */
diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index f73ca59..44c8d0d 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -4623,13 +4623,8 @@ asmlinkage __visible void lockdep_sys_exit(void)
 	/*
 	 * The lock history for each syscall should be independent. So wipe the
 	 * slate clean on return to userspace.
-	 *
-	 * crossrelease_hist_end() works well here even when getting here
-	 * without starting (i.e. just after forking), because it rolls back
-	 * the index to point to the last entry, which is already invalid.
 	 */
-	crossrelease_hist_end(XHLOCK_PROC);
-	crossrelease_hist_start(XHLOCK_PROC, false);
+	lockdep_invariant_state(false);
 }
 
 void lockdep_rcu_suspicious(const char *file, const int line, const char *s)
@@ -4723,19 +4718,47 @@ static inline void invalidate_xhlock(struct hist_lock *xhlock)
 }
 
 /*
- * Lock history stacks; we have 3 nested lock history stacks:
+ * Lock history stacks; we have 2 nested lock history stacks:
  *
  *   HARD(IRQ)
  *   SOFT(IRQ)
- *   PROC(ess)
  *
  * The thing is that once we complete a HARD/SOFT IRQ the future task locks
  * should not depend on any of the locks observed while running the IRQ.  So
  * what we do is rewind the history buffer and erase all our knowledge of that
  * temporal event.
- *
- * The PROCess one is special though; it is used to annotate independence
- * inside a task.
+ */
+
+void crossrelease_hist_start(enum xhlock_context_t c)
+{
+	struct task_struct *cur = current;
+
+	if (!cur->xhlocks)
+		return;
+
+	cur->xhlock_idx_hist[c] = cur->xhlock_idx;
+	cur->hist_id_save[c]    = cur->hist_id;
+}
+
+void crossrelease_hist_end(enum xhlock_context_t c)
+{
+	struct task_struct *cur = current;
+
+	if (cur->xhlocks) {
+		unsigned int idx = cur->xhlock_idx_hist[c];
+		struct hist_lock *h = &xhlock(idx);
+
+		cur->xhlock_idx = idx;
+
+		/* Check if the ring was overwritten. */
+		if (h->hist_id != cur->hist_id_save[c])
+			invalidate_xhlock(h);
+	}
+}
+
+/*
+ * lockdep_invariant_state() is used to annotate independence inside a task, to
+ * make one task look like multiple independent 'tasks'.
  *
  * Take for instance workqueues; each work is independent of the last. The
  * completion of a future work does not depend on the completion of a past work
@@ -4758,40 +4781,14 @@ static inline void invalidate_xhlock(struct hist_lock *xhlock)
  * entry. Similarly, independence per-definition means it does not depend on
  * prior state.
  */
-void crossrelease_hist_start(enum xhlock_context_t c, bool force)
+void lockdep_invariant_state(bool force)
 {
-	struct task_struct *cur = current;
-
-	if (!cur->xhlocks)
-		return;
-
 	/*
 	 * We call this at an invariant point, no current state, no history.
+	 * Verify the former, enforce the latter.
 	 */
-	if (c == XHLOCK_PROC) {
-		/* verified the former, ensure the latter */
-		WARN_ON_ONCE(!force && cur->lockdep_depth);
-		invalidate_xhlock(&xhlock(cur->xhlock_idx));
-	}
-
-	cur->xhlock_idx_hist[c] = cur->xhlock_idx;
-	cur->hist_id_save[c]    = cur->hist_id;
-}
-
-void crossrelease_hist_end(enum xhlock_context_t c)
-{
-	struct task_struct *cur = current;
-
-	if (cur->xhlocks) {
-		unsigned int idx = cur->xhlock_idx_hist[c];
-		struct hist_lock *h = &xhlock(idx);
-
-		cur->xhlock_idx = idx;
-
-		/* Check if the ring was overwritten. */
-		if (h->hist_id != cur->hist_id_save[c])
-			invalidate_xhlock(h);
-	}
+	WARN_ON_ONCE(!force && current->lockdep_depth);
+	invalidate_xhlock(&xhlock(current->xhlock_idx));
 }
 
 static int cross_lock(struct lockdep_map *lock)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index c033189..ab3c0dc 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -2094,8 +2094,8 @@ __acquires(&pool->lock)
 	lock_map_acquire(&pwq->wq->lockdep_map);
 	lock_map_acquire(&lockdep_map);
 	/*
-	 * Strictly speaking we should do start(PROC) without holding any
-	 * locks, that is, before these two lock_map_acquire()'s.
+	 * Strictly speaking we should mark the invariant state without holding
+	 * any locks, that is, before these two lock_map_acquire()'s.
 	 *
 	 * However, that would result in:
 	 *
@@ -2107,14 +2107,14 @@ __acquires(&pool->lock)
 	 * Which would create W1->C->W1 dependencies, even though there is no
 	 * actual deadlock possible. There are two solutions, using a
 	 * read-recursive acquire on the work(queue) 'locks', but this will then
-	 * hit the lockdep limitation on recursive locks, or simly discard
+	 * hit the lockdep limitation on recursive locks, or simply discard
 	 * these locks.
 	 *
 	 * AFAICT there is no possible deadlock scenario between the
 	 * flush_work() and complete() primitives (except for single-threaded
 	 * workqueues), so hiding them isn't a problem.
 	 */
-	crossrelease_hist_start(XHLOCK_PROC, true);
+	lockdep_invariant_state(true);
 	trace_workqueue_execute_start(work);
 	worker->current_func(work);
 	/*
@@ -2122,7 +2122,6 @@ __acquires(&pool->lock)
 	 * point will only record its address.
 	 */
 	trace_workqueue_execute_end(work);
-	crossrelease_hist_end(XHLOCK_PROC);
 	lock_map_release(&lockdep_map);
 	lock_map_release(&pwq->wq->lockdep_map);
 

  reply	other threads:[~2017-08-29 14:27 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-23 11:58 [PATCH 0/4] workqueue and lockdep stuffs Peter Zijlstra
2017-08-23 11:58 ` [PATCH 1/4] workqueue: Use TASK_IDLE Peter Zijlstra
2017-08-23 13:31   ` Tejun Heo
2017-08-23 11:58 ` [PATCH 2/4] lockdep/selftests: Add mixed read-write ABBA tests Peter Zijlstra
2017-08-23 11:58 ` [PATCH 3/4] workqueue/lockdep: Fix flush_work() annotation Peter Zijlstra
2017-08-23 11:58 ` [PATCH 4/4] lockdep: Fix workqueue crossrelease annotation Peter Zijlstra
2017-08-24  2:18   ` Byungchul Park
2017-08-24 14:02     ` Peter Zijlstra
2017-08-25  1:11       ` Byungchul Park
2017-08-29  8:59         ` Peter Zijlstra
2017-08-29 14:23           ` tip-bot for Peter Zijlstra [this message]
2017-08-29 16:02           ` Byungchul Park
2017-08-29 18:47             ` Peter Zijlstra
2017-08-30  2:09           ` Byungchul Park
2017-08-30  7:41             ` Byungchul Park
2017-08-30  8:53               ` Peter Zijlstra
2017-08-30  9:01                 ` Byungchul Park
2017-08-30  9:12                   ` Peter Zijlstra
2017-08-30  9:14                     ` Peter Zijlstra
2017-08-30  9:35                       ` Byungchul Park
2017-08-30  9:24                     ` Byungchul Park
2017-08-30 11:25                       ` Byungchul Park
2017-08-30 12:49                         ` Byungchul Park
2017-08-31  7:26                         ` Byungchul Park
2017-08-31  8:04                         ` Peter Zijlstra
2017-08-31  8:15                           ` Byungchul Park
2017-08-31  8:34                             ` Peter Zijlstra
2017-09-01  2:05                               ` Byungchul Park
2017-09-01  9:47                                 ` Peter Zijlstra
2017-09-01 10:16                                   ` Byungchul Park
2017-09-01 12:09                                     ` 박병철/선임연구원/SW Platform(연)AOT팀(byungchul.park@lge.com)
2017-09-01 12:38                                     ` Peter Zijlstra
2017-09-01 13:51                                       ` Byungchul Park
2017-09-01 16:38                                         ` Peter Zijlstra
2017-09-04  1:30                                           ` Byungchul Park
2017-09-04  2:08                                             ` Byungchul Park
2017-09-04 11:42                                             ` Peter Zijlstra
2017-09-05  0:38                                               ` Byungchul Park
2017-09-05  7:08                                                 ` Peter Zijlstra
2017-09-05  7:19                                                   ` Peter Zijlstra
2017-09-05  8:57                                                     ` Byungchul Park
2017-09-05  9:36                                                       ` Peter Zijlstra
2017-09-05 10:31                                                         ` Byungchul Park
2017-09-05 10:52                                                           ` Peter Zijlstra
2017-09-05 11:24                                                             ` Byungchul Park
2017-09-05 10:58                                                           ` Byungchul Park
2017-09-05 13:46                                                             ` Peter Zijlstra
2017-09-05 23:52                                                               ` Byungchul Park
2017-09-06  0:42                                                                 ` Boqun Feng
2017-09-06  1:32                                                                   ` Byungchul Park
2017-09-06 23:59                                                                     ` Byungchul Park
2017-09-07  0:11                                                                     ` Byungchul Park
2017-09-06  0:48                                                               ` Byungchul Park
2017-09-05  8:30                                                   ` Byungchul Park
2017-08-31  8:07                       ` Peter Zijlstra
2017-08-25  4:39       ` Byungchul Park
2017-08-29  6:46   ` Byungchul Park
2017-08-29  9:01     ` Peter Zijlstra
2017-08-29 16:12       ` Byungchul Park
2017-08-23 13:32 ` [PATCH 0/4] workqueue and lockdep stuffs Tejun Heo
2017-08-23 13:45   ` Peter Zijlstra

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=tip-f52be5708076b75a045ac52c6fef3fffb8300525@git.kernel.org \
    --to=tipbot@zytor.com \
    --cc=byungchul.park@lge.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tip-commits@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.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).