From: "J . Bruce Fields" <bfields@fieldses.org>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Jeff Layton <jlayton@kernel.org>,
Miklos Szeredi <miklos@szeredi.hu>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
overlayfs <linux-unionfs@vger.kernel.org>
Subject: Re: [PATCH v2] locks: eliminate false positive conflicts for write lease
Date: Thu, 13 Jun 2019 10:08:04 -0400 [thread overview]
Message-ID: <20190613140804.GA2145@fieldses.org> (raw)
In-Reply-To: <CAOQ4uxi-uEhAbqVeYbeqAR=TXpthZHdUKkaZJB7fy1TgdZObjQ@mail.gmail.com>
On Thu, Jun 13, 2019 at 04:28:49PM +0300, Amir Goldstein wrote:
> On Thu, Jun 13, 2019 at 4:22 PM Jeff Layton <jlayton@kernel.org> wrote:
> > Looks good to me. Aside from the minor nit above:
> >
> > Reviewed-by: Jeff Layton <jlayton@kernel.org>
> >
> > I have one file locking patch queued up for v5.3 so far, but nothing for
> > v5.2. Miklos or Bruce, if either of you have anything to send to Linus
> > for v5.2 would you mind taking this one too?
> >
>
> Well. I did send a fix patch to Miklos for a bug introduced in v5.2-rc4,
> so...
I could take it. I've modified it as below.
I'm very happy with the patch, but not so much with the idea of 5.2 and
stable.
It seems like a subtle change with some possibility of unintended side
effects. (E.g. I don't think this is true any more, but my memory is
that for a long time the only thing stopping nfsd from giving out
(probably broken) write delegations was an extra reference that it held
during processing.) And if the overlayfs bug's been there since 4.19,
then waiting a little longer seems OK?
--b.
diff --git a/fs/locks.c b/fs/locks.c
index c7912b0fdeea..2056595751e8 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -1779,7 +1779,7 @@ check_conflicting_open(struct file *filp, const long arg, int flags)
/* Make sure that only read/write count is from lease requestor */
if (filp->f_mode & FMODE_WRITE)
self_wcount = 1;
- else if ((filp->f_mode & (FMODE_READ | FMODE_WRITE)) == FMODE_READ)
+ else if (filp->f_mode & FMODE_READ)
self_rcount = 1;
if (arg == F_WRLCK && (wcount != self_wcount ||
next prev parent reply other threads:[~2019-06-13 15:06 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-12 17:24 [PATCH v2] locks: eliminate false positive conflicts for write lease Amir Goldstein
2019-06-12 18:31 ` J . Bruce Fields
2019-06-13 14:13 ` Miklos Szeredi
2019-06-13 14:31 ` J . Bruce Fields
2019-06-13 15:47 ` Amir Goldstein
2019-06-13 15:50 ` Jeff Layton
2019-06-13 15:55 ` Amir Goldstein
2019-06-13 13:22 ` Jeff Layton
2019-06-13 13:28 ` Amir Goldstein
2019-06-13 14:08 ` J . Bruce Fields [this message]
2019-07-08 16:09 ` Amir Goldstein
2019-07-09 11:02 ` 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=20190613140804.GA2145@fieldses.org \
--to=bfields@fieldses.org \
--cc=amir73il@gmail.com \
--cc=jlayton@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=linux-unionfs@vger.kernel.org \
--cc=miklos@szeredi.hu \
/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).