All of lore.kernel.org
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Jeff Layton <jlayton@poochiereds.net>,
	"Kirill A. Shutemov" <kirill@shutemov.name>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Christoph Hellwig <hch@lst.de>,
	Dave Chinner <david@fromorbit.com>,
	Sasha Levin <sasha.levin@oracle.com>
Subject: Re: [GIT PULL] please pull file-locking related changes for v3.20
Date: Tue, 17 Feb 2015 14:45:11 -0500	[thread overview]
Message-ID: <20150217194511.GE27900@fieldses.org> (raw)
In-Reply-To: <CA+55aFyM6yifUDZdUF=8wsbJY-NGvs74SCZpp5u7Wnhbxq6Qhg@mail.gmail.com>

On Tue, Feb 17, 2015 at 11:41:40AM -0800, Linus Torvalds wrote:
> On Tue, Feb 17, 2015 at 11:27 AM, Jeff Layton <jlayton@poochiereds.net> wrote:
> >
> > What about this instead then?
> 
> No. Really.
> 
> > - leave the "drop the spinlock" thing in place in flock_lock_file for
> >   v3.20
> 
> No. The whole concept of "drop the lock in the middle" is *BROKEN*.
> It's seriously crap. It's not just a bug, it's a really fundamentally
> wrong thing to do.
> 
> > - change locks_remove_flock to just walk the list and delete any locks
> >   associated with the filp being closed
> 
> No. That's still wrong. You can have two people holding a write-lock.
> Seriously. That's *shit*.
> 
> The "drop the spinlock in the middle" must go. There's not even any
> reason for it. Just get rid of it. There can be no deadlock if you get
> rid of it, because
> 
>  - we hold the flc_lock over the whole event, so we can never see any
> half-way state
> 
>  - if we actually decide to sleep (due to conflicting locks) and
> return FILE_LOCK_DEFERRED, we will drop the lock before actually
> sleeping, so nobody else will be deadlocking on this file lock. So any
> *other* person who tries to do an upgrade will not sleep, because the
> pending upgrade will have moved to the blocking list (that whole
> "locks_insert_block" part.

Whoops, you're right, I was forgetting that wait happens up in
flock_lock_file_wait(), OK.

--b.

> Ergo, either we'll upgrade the lock (atomically, within flc_lock), or
> we will drop the lock (possibly moving it to the blocking list). I
> don't see a deadlock.
> 
> I think your (and mine - but mine had the more fundamental problem of
> never setting "old_fl" correctly at all) patch had a deadlock because
> you didn't actually remove the old lock when you returned
> FILE_LOCK_DEFERRED.
> 
> But I think the correct minimal patch is actually to just remove the
> "if (found)" statement.
> 
>                        Linus

  reply	other threads:[~2015-02-17 19:45 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-09 10:55 [GIT PULL] please pull file-locking related changes for v3.20 Jeff Layton
2015-02-16 13:32 ` Kirill A. Shutemov
2015-02-16 14:00   ` Jeff Layton
2015-02-16 18:46     ` Linus Torvalds
2015-02-16 19:24       ` Linus Torvalds
2015-02-16 19:59         ` Jeff Layton
2015-02-17  0:02         ` Jeff Layton
2015-02-17  0:21           ` Linus Torvalds
2015-02-17  0:35             ` Jeff Layton
2015-02-17 19:08         ` J. Bruce Fields
2015-02-17 19:13           ` Linus Torvalds
2015-02-17 19:27             ` Jeff Layton
2015-02-17 19:41               ` Linus Torvalds
2015-02-17 19:45                 ` J. Bruce Fields [this message]
2015-02-17 20:12                 ` Jeff Layton
2015-02-17 20:17                   ` Linus Torvalds
2015-02-17 19:29             ` Linus Torvalds
2015-02-26 11:00             ` One Thousand Gnomes
2015-02-26 14:45               ` J. Bruce Fields
2015-02-26 15:09                 ` J. Bruce Fields

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=20150217194511.GE27900@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=david@fromorbit.com \
    --cc=hch@lst.de \
    --cc=jlayton@poochiereds.net \
    --cc=kirill@shutemov.name \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sasha.levin@oracle.com \
    --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 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.