All of lore.kernel.org
 help / color / mirror / Atom feed
From: NeilBrown <neilb@suse.com>
To: Jeff Layton <jlayton@kernel.org>, linux-fsdevel@vger.kernel.org
Cc: bfields@fieldses.org, asn@redhat.com
Subject: Re: [PATCH] locks: ignore same lock in blocked_lock_hash
Date: Fri, 22 Mar 2019 08:51:27 +1100	[thread overview]
Message-ID: <87a7hn7v6o.fsf@notabene.neil.brown.name> (raw)
In-Reply-To: <20190321112744.7832-1-jlayton@kernel.org>

[-- Attachment #1: Type: text/plain, Size: 2063 bytes --]

On Thu, Mar 21 2019, 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.
>
> 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

There is a weak pattern of using

URL: 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;
> +

I would always write this with the value being tested first, and the
value it is being tested against second (and yes, I know that equality
is mathematically symmetric).

 if (block_fl == caller_fl)
    return 0;

But .... whatever.  At least your ordering matches the
posix_same_owner() below, and consistency is a good thing too.

Thanks,
NeilBrown


>  		if (posix_same_owner(caller_fl, block_fl))
>  			return 1;
>  	}
> -- 
> 2.20.1

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

  reply	other threads:[~2019-03-21 21:51 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 [this message]
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=87a7hn7v6o.fsf@notabene.neil.brown.name \
    --to=neilb@suse.com \
    --cc=asn@redhat.com \
    --cc=bfields@fieldses.org \
    --cc=jlayton@kernel.org \
    --cc=linux-fsdevel@vger.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 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.