From: Linus Torvalds <torvalds@linux-foundation.org>
To: Jeff Layton <jlayton@poochiereds.net>
Cc: "Kirill A. Shutemov" <kirill@shutemov.name>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"J. Bruce Fields" <bfields@fieldses.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: Mon, 16 Feb 2015 16:21:30 -0800 [thread overview]
Message-ID: <CA+55aFzOU93LvBLWw5vvLLFFsMiHJuH8Yc=Zn4N6NSDwp5acUg@mail.gmail.com> (raw)
In-Reply-To: <20150216190254.3b66a9ba@tlielax.poochiereds.net>
[-- Attachment #1: Type: text/plain, Size: 1124 bytes --]
On Mon, Feb 16, 2015 at 4:02 PM, Jeff Layton <jlayton@poochiereds.net> wrote:
>
> Now that I look, it may be best to just revert this whole set for now.
> Linus, are you amenable to doing that?
Sure. But I'd prefer seeing how hard it would be to fix things first.
If this was at the end of the release cycle, I'd revert it
immediately. As it is, try to see how had it is.
The bugs I found might be as easy as just the attached (TOTALLY
UNTESTED) patch. The comment about a higher-priority process and
sched_resced() is just complete and utter crap. If somebody holds a
read lock and upgrades it to a write lock, there is absolutely *zero*
reason to let some higher-priority process get the write-lock first -
that's just simply semantically wrong bullshit. "Higher priority" does
not mean "can punch through locks".
Removing the silly incorrect counts should be trivial too. There
really are not very many users, and they can just walk the list
instead.
Now, if you've found other more fundamental bugs that look unfixable,
then that might mean that reverting it all is unavoidable, but..
Linus
[-- Attachment #2: patch.diff --]
[-- Type: text/plain, Size: 1813 bytes --]
fs/locks.c | 22 +++++++---------------
1 file changed, 7 insertions(+), 15 deletions(-)
diff --git a/fs/locks.c b/fs/locks.c
index 4753218f308e..8fbf81429608 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -867,12 +867,11 @@ static int posix_locks_deadlock(struct file_lock *caller_fl,
*/
static int flock_lock_file(struct file *filp, struct file_lock *request)
{
- struct file_lock *new_fl = NULL;
+ struct file_lock *new_fl = NULL, *old_fl = NULL;
struct file_lock *fl;
struct file_lock_context *ctx;
struct inode *inode = file_inode(filp);
int error = 0;
- bool found = false;
LIST_HEAD(dispose);
ctx = locks_get_lock_context(inode);
@@ -894,27 +893,18 @@ static int flock_lock_file(struct file *filp, struct file_lock *request)
continue;
if (request->fl_type == fl->fl_type)
goto out;
- found = true;
- locks_delete_lock_ctx(fl, &ctx->flc_flock_cnt, &dispose);
+ old_fl = NULL;
break;
}
if (request->fl_type == F_UNLCK) {
- if ((request->fl_flags & FL_EXISTS) && !found)
+ if (old_fl)
+ locks_delete_lock_ctx(old_fl, &ctx->flc_flock_cnt, &dispose);
+ else if (request->fl_flags & FL_EXISTS)
error = -ENOENT;
goto out;
}
- /*
- * If a higher-priority process was blocked on the old file lock,
- * give it the opportunity to lock the file.
- */
- if (found) {
- spin_unlock(&ctx->flc_lock);
- cond_resched();
- spin_lock(&ctx->flc_lock);
- }
-
find_conflict:
list_for_each_entry(fl, &ctx->flc_flock, fl_list) {
if (!flock_locks_conflict(request, fl))
@@ -928,6 +918,8 @@ find_conflict:
}
if (request->fl_flags & FL_ACCESS)
goto out;
+ if (old_fl)
+ locks_delete_lock_ctx(old_fl, &ctx->flc_flock_cnt, &dispose);
locks_copy_lock(new_fl, request);
locks_insert_lock_ctx(new_fl, &ctx->flc_flock_cnt, &ctx->flc_flock);
new_fl = NULL;
next prev parent reply other threads:[~2015-02-17 0:21 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 [this message]
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
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='CA+55aFzOU93LvBLWw5vvLLFFsMiHJuH8Yc=Zn4N6NSDwp5acUg@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--cc=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 \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).