From: "J . Bruce Fields" <bfields@fieldses.org>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: Amir Goldstein <amir73il@gmail.com>,
Jeff Layton <jlayton@poochiereds.net>,
linux-fsdevel@vger.kernel.org,
Linux NFS 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:31:51 -0400 [thread overview]
Message-ID: <20190613143151.GC2145@fieldses.org> (raw)
In-Reply-To: <CAJfpegvj0NHQrPcHFd=b47M-uz2CY6Hnamk_dJvcrUtwW65xBw@mail.gmail.com>
On Thu, Jun 13, 2019 at 04:13:15PM +0200, Miklos Szeredi wrote:
> On Wed, Jun 12, 2019 at 8:31 PM J . Bruce Fields <bfields@fieldses.org> wrote:
> >
> > How do opens for execute work? I guess they create a struct file with
> > FMODE_EXEC and FMODE_RDONLY set and they decrement i_writecount. Do
> > they also increment i_readcount? Reading do_open_execat and alloc_file,
> > looks like it does, so, good, they should conflict with write leases,
> > which sounds right.
>
> Right, but then why this:
>
> > > + /* Eliminate deny writes from actual writers count */
> > > + if (wcount < 0)
> > > + wcount = 0;
>
> It's basically a no-op, as you say. And it doesn't make any sense
> logically, since denying writes *should* deny write leases as well...
Yes. I feel like the negative writecount case is a little nonobvious,
so maybe replace that by a comment, something like this?:
--b.
diff --git a/fs/locks.c b/fs/locks.c
index 2056595751e8..379829b913c1 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -1772,11 +1772,12 @@ check_conflicting_open(struct file *filp, const long arg, int flags)
if (arg == F_RDLCK && wcount > 0)
return -EAGAIN;
- /* Eliminate deny writes from actual writers count */
- if (wcount < 0)
- wcount = 0;
-
- /* Make sure that only read/write count is from lease requestor */
+ /*
+ * Make sure that only read/write count is from lease requestor.
+ * Note that this will result in denying write leases when wcount
+ * is negative, which is what we want. (We shouldn't grant
+ * write leases on files open for execution.)
+ */
if (filp->f_mode & FMODE_WRITE)
self_wcount = 1;
else if (filp->f_mode & FMODE_READ)
next prev parent reply other threads:[~2019-06-13 15:02 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 [this message]
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
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=20190613143151.GC2145@fieldses.org \
--to=bfields@fieldses.org \
--cc=amir73il@gmail.com \
--cc=jlayton@poochiereds.net \
--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 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.