All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@kernel.org>
To: linux-fsdevel@vger.kernel.org
Cc: neilb@suse.com, bfields@fieldses.org, asn@redhat.com
Subject: [PATCH] locks: ignore same lock in blocked_lock_hash
Date: Thu, 21 Mar 2019 07:27:44 -0400	[thread overview]
Message-ID: <20190321112744.7832-1-jlayton@kernel.org> (raw)

Andreas reported that he was seeing the tdbtorture test fail in
some cases with -EDEADLCK when it wasn't before. Some debugging
showed that deadlock detection was sometimes discovering the
caller's lock request itself in a dependency chain.

If posix_locks_deadlock() fails to find a deadlock, the caller_fl
will be passed to __locks_insert_block(), and this wakes up all
locks that are blocked on caller_fl, clearing the fl_blocker link.

So if posix_locks_deadlock() finds caller_fl while searching for
a deadlock, it can be sure that link in the cycle is about to be
broken and it need not treat it as the cause of a deadlock.

More details here: https://bugzilla.kernel.org/show_bug.cgi?id=202975

Cc: stable@vger.kernel.org
Fixes: 5946c4319ebb ("fs/locks: allow a lock request to block other requests.")
Reported-by: Andreas Schneider <asn@redhat.com>
Signed-off-by: Neil Brown <neilb@suse.com>
Signed-off-by: Jeff Layton <jlayton@kernel.org>
---
 fs/locks.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/fs/locks.c b/fs/locks.c
index eaa1cfaf73b0..b074f6d7fd2d 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -1023,6 +1023,10 @@ static int posix_locks_deadlock(struct file_lock *caller_fl,
 	while ((block_fl = what_owner_is_waiting_for(block_fl))) {
 		if (i++ > MAX_DEADLK_ITERATIONS)
 			return 0;
+
+		if (caller_fl == block_fl)
+			return 0;
+
 		if (posix_same_owner(caller_fl, block_fl))
 			return 1;
 	}
-- 
2.20.1


             reply	other threads:[~2019-03-21 11:27 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-21 11:27 Jeff Layton [this message]
2019-03-21 21:51 ` [PATCH] locks: ignore same lock in blocked_lock_hash NeilBrown
2019-03-22  0:42 ` J. Bruce Fields
2019-03-22  1:58   ` NeilBrown
2019-03-22 20:27     ` J. Bruce Fields
2019-03-23 12:08       ` [PATCH v2] " Jeff Layton
2019-03-24  0:51         ` NeilBrown
2019-03-25 12:31           ` Jeff Layton
2019-03-25 12:32             ` [PATCH v3] locks: wake any locks blocked on request before deadlock check Jeff Layton
2019-03-25 22:09               ` J. Bruce Fields
2019-03-25 22:33               ` NeilBrown
2019-03-23 12:05     ` [PATCH] locks: ignore same lock in blocked_lock_hash Jeff Layton

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=20190321112744.7832-1-jlayton@kernel.org \
    --to=jlayton@kernel.org \
    --cc=asn@redhat.com \
    --cc=bfields@fieldses.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=neilb@suse.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.