Re: [GIT PULL] please pull file-locking related changes for v3.20

From: Linus Torvalds <torvalds@linux-foundation.org>
To: "J. Bruce Fields" <bfields@fieldses.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 11:29:56 -0800	[thread overview]
Message-ID: <CA+55aFxmeTp1L19Bnn4fjhyPvjQUMkfP2+KAgAcWoY6Uxrz41w@mail.gmail.com> (raw)
In-Reply-To: <CA+55aFxwuHCr3evNEfpAE-jGG+279PnevvxscvG-8q4YiYEv-g@mail.gmail.com>

On Tue, Feb 17, 2015 at 11:13 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> That said, I'm not at all sure about the "we're stuck with it". We can
> improve the semantics without anybody noticing, because it's not like
> anybody could *depend* on the weaker semantics - they needed
> particular races and timings to hit anyway.

.. that said, it's true that we cannot do the FILE_LOCK_DEFERRED thing
for multiple blockers that already hold a lock. One of them has to
release its lock for other lockers to make progress. So I guess the
weak model of dropping a read lock before taking a write lock is
actually required.

That sleep in the middle with dropping the lock is still complete
crap, though. You can't do it. If you drop the lock, you have to
repeat the while cycle, not just sleep and continue.

Or just go to sleep, waiting for the conflicting lock to also be dropped.

So maybe just removing that whole "if (found) { reschedule }" - but
leaving the "drop early - is the right thing to do.

                          Linus