linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.com>
To: peterz@infradead.org
Cc: linux-kernel@vger.kernel.org, mingo@redhat.com,
	David Sterba <dsterba@suse.com>
Subject: [PATCH] lockdep: introduce lockdep_assert_not_held()
Date: Thu, 13 Jun 2019 15:36:04 +0200	[thread overview]
Message-ID: <20190613133604.9889-1-dsterba@suse.com> (raw)

Add an assertion that a lock is not held, suitable for the following
(simplified) usecase in filesystems:

- filesystem write
  - lock(&big_filesystem_lock)
  - kmalloc(GFP_KERNEL)
    - trigger dirty data write to get more memory
      - find dirty pages
      - call filesystem write
        - lock(&big_filesystem_lock)
	  deadlock

The cause here is the use of GFP_KERNEL that does not exclude poking
filesystems to allow freeing some memory. Such scenario is a bug, so the
use of GFP_NOFS is the right flag.

The annotation can help catch such bugs during development because
the actual deadlock could be hard to hit in practice.

Signed-off-by: David Sterba <dsterba@suse.com>
---
 Documentation/locking/lockdep-design.txt | 5 +++++
 include/linux/lockdep.h                  | 5 +++++
 2 files changed, 10 insertions(+)

diff --git a/Documentation/locking/lockdep-design.txt b/Documentation/locking/lockdep-design.txt
index 39fae143c9cb..8b3013aaf518 100644
--- a/Documentation/locking/lockdep-design.txt
+++ b/Documentation/locking/lockdep-design.txt
@@ -211,6 +211,11 @@ that nobody tampered with the lock, e.g. kernel/sched/sched.h
 	lockdep_unpin_lock(&rq->lock, rf->cookie);
   }
 
+In some contexts it is useful to assert that a given lock is not held.  A
+typical example are filesystems that must avoid recursion to their code when
+a memory allocation triggers write of dirty data. When the allocation is done
+with a lock taken, re-entering the code would cause a deadlock.
+
 While comments about locking requirements might provide useful information,
 the runtime checks performed by annotations are invaluable when debugging
 locking problems and they carry the same level of details when inspecting
diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
index 6e2377e6c1d6..a6682104bd95 100644
--- a/include/linux/lockdep.h
+++ b/include/linux/lockdep.h
@@ -397,6 +397,10 @@ extern void lock_unpin_lock(struct lockdep_map *lock, struct pin_cookie);
 		WARN_ON_ONCE(debug_locks && !lockdep_is_held(l));	\
 	} while (0)
 
+#define lockdep_assert_not_held(l)	do {			\
+		WARN_ON(debug_locks && lockdep_is_held(l));	\
+	} while (0)
+
 #define lockdep_recursing(tsk)	((tsk)->lockdep_recursion)
 
 #define lockdep_pin_lock(l)	lock_pin_lock(&(l)->dep_map)
@@ -469,6 +473,7 @@ struct lockdep_map { };
 #define lockdep_assert_held_exclusive(l)	do { (void)(l); } while (0)
 #define lockdep_assert_held_read(l)		do { (void)(l); } while (0)
 #define lockdep_assert_held_once(l)		do { (void)(l); } while (0)
+#define lockdep_assert_not_held(l)		do { (void)(l); } while (0)
 
 #define lockdep_recursing(tsk)			(0)
 
-- 
2.21.0


             reply	other threads:[~2019-06-13 15:13 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-13 13:36 David Sterba [this message]
2019-06-28 12:20 ` [PATCH] lockdep: introduce lockdep_assert_not_held() David Sterba

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=20190613133604.9889-1-dsterba@suse.com \
    --to=dsterba@suse.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.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).