All of lore.kernel.org
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: Jeff Layton <jlayton@kernel.org>
Cc: linux-fsdevel@vger.kernel.org, neilb@suse.com, asn@redhat.com
Subject: Re: [PATCH v3] locks: wake any locks blocked on request before deadlock check
Date: Mon, 25 Mar 2019 18:09:13 -0400	[thread overview]
Message-ID: <20190325220913.GA22644@fieldses.org> (raw)
In-Reply-To: <20190325123252.10211-1-jlayton@kernel.org>

On Mon, Mar 25, 2019 at 08:32:52AM -0400, Jeff Layton wrote:
> 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.
> 
> While we remove the request from the blocked_lock_hash prior to
> reattempting to acquire it, any locks that are blocked on that request
> will still be present in the hash and will still have their fl_blocker
> pointer set to the current request.

This description is a lot easier for me to follow, thanks!

> This causes posix_locks_deadlock to find a deadlock dependency chain
> when it shouldn't, as a lock request cannot block itself.
> 
> We are going to end up waking all of those blocked locks anyway when we
> go to reinsert the request back into the blocked_lock_hash, so just do
> it prior to checking for deadlocks. This ensures that any lock blocked
> on the current request will no longer be part of any blocked request
> chain.

Looks right to me.

--b.

> 
> URL: https://bugzilla.kernel.org/show_bug.cgi?id=202975
> Fixes: 5946c4319ebb ("fs/locks: allow a lock request to block other requests.")
> Cc: stable@vger.kernel.org
> 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 | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/fs/locks.c b/fs/locks.c
> index eaa1cfaf73b0..71d0c6c2aac5 100644
> --- a/fs/locks.c
> +++ b/fs/locks.c
> @@ -1160,6 +1160,11 @@ static int posix_lock_inode(struct inode *inode, struct file_lock *request,
>  			 */
>  			error = -EDEADLK;
>  			spin_lock(&blocked_lock_lock);
> +			/*
> +			 * Ensure that we don't find any locks blocked on this
> +			 * request during deadlock detection.
> +			 */
> +			__locks_wake_up_blocks(request);
>  			if (likely(!posix_locks_deadlock(request, fl))) {
>  				error = FILE_LOCK_DEFERRED;
>  				__locks_insert_block(fl, request,
> -- 
> 2.20.1

  reply	other threads:[~2019-03-25 22:09 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-21 11:27 [PATCH] locks: ignore same lock in blocked_lock_hash Jeff Layton
2019-03-21 21:51 ` 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 [this message]
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=20190325220913.GA22644@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=asn@redhat.com \
    --cc=jlayton@kernel.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.