From: "J. Bruce Fields" <bfields@fieldses.org>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Jeff Layton <jlayton@kernel.org>,
Volker.Lendecke@sernet.de, samba-technical@lists.samba.org,
Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Pavel Shilovsky <piastryyy@gmail.com>
Subject: Re: Better interop for NFS/SMB file share mode/reservation
Date: Fri, 15 Feb 2019 15:09:38 -0500 [thread overview]
Message-ID: <20190215200938.GC22354@fieldses.org> (raw)
In-Reply-To: <CAOQ4uxhORdbODd01xrm6frbBUU1-U=5Rh86ZU63CrybpdyCL+A@mail.gmail.com>
On Fri, Feb 15, 2019 at 09:31:48AM +0200, Amir Goldstein wrote:
> On Thu, Feb 14, 2019 at 10:51 PM J. Bruce Fields <bfields@fieldses.org> wrote:
> >
> > On Fri, Feb 08, 2019 at 10:31:07PM +0200, Amir Goldstein wrote:
> > > On Fri, Feb 8, 2019 at 10:17 PM J. Bruce Fields <bfields@fieldses.org> wrote:
> > > > On Fri, Feb 08, 2019 at 10:02:43PM +0200, Amir Goldstein wrote:
> > > > > On Fri, Feb 8, 2019 at 5:51 PM J. Bruce Fields <bfields@fieldses.org> wrote:
> > > > > > On Fri, Feb 08, 2019 at 04:45:46PM +0200, Amir Goldstein wrote:
> > > > > > > - check_conflicting_open() is changed to use inode_is_open_for_read()
> > > > > > > instead of checking d_count and i_count.
> > > > > >
> > > > > > Independently of the rest, I'd love to do away with those
> > > > > > d_count/i_count checks. What's inode_is_open_for_read()?
> > > > > >
> > > > >
> > > > > It would look maybe something like this:
> > > > >
> > > > > static inline bool file_is_open_for_read(const struct inode *file)
> > > > > {
> > > > > struct inode *inode = file_inode(file);
> > > > > int countself = (file->f_mode & (FMODE_READ | FMODE_WRITE)) ==
> > > > > FMODE_READ) ? 1 : 0;
> > > > >
> > > > > return atomic_read(&inode->i_readcount) > countself;
> > > > > }
> > > > >
> > > > > And it would allow for acquiring F_WRLCK lease if other
> > > > > instances of inode are open O_PATH.
> > > > > A slight change of semantics that seems harmless(?)
> > > > > and will allow some flexibility.
> > > >
> > > > How did I not know about i_readcount? (Looking) I guess it would mean
> > > > adding some dependence on CONFIG_IMA, hm.
> > > >
> > >
> > > Yes, or we remove ifdef CONFIG_IMA from i_readcount.
> > > I am not sure if the concern was size of struct inode
> > > (shouldn't increase on 64bit arch) or the accounting on
> > > open/close. The impact doesn't look significant (?)..
> >
> > Looks like the original patch was d984ea604943bb "fs: move i_readcount".
> > I did some googling around and looked at the discussion summarized by
> > https://lwn.net/Articles/410895/ but can't find useful discussion of
> > i_readcount impact.
> >
> > Looks like CONFIG_IMA is on in Fedora and RHEL, for what it's worth.
> >
> > Maybe something like this?
> >
> > --b.
> >
> > commit 02cfda99ed8c
> > Author: J. Bruce Fields <bfields@redhat.com>
> > Date: Thu Feb 14 15:02:02 2019 -0500
> >
> > locks: use i_readcount to detect lease conflicts
> >
> > The lease code currently uses the inode and dentry refcounts to detect
> > whether someone has a file open for read. This seems fragile. Use
> > i_readcount instead.
> >
> > Signed-off-by: J. Bruce Fields <bfields@redhat.com>
> >
> > diff --git a/fs/locks.c b/fs/locks.c
> > index ff6af2c32601..299abad65545 100644
> > --- a/fs/locks.c
> > +++ b/fs/locks.c
> > @@ -1769,8 +1769,7 @@ check_conflicting_open(const struct dentry *dentry, const long arg, int flags)
> > if ((arg == F_RDLCK) && inode_is_open_for_write(inode))
> > return -EAGAIN;
> >
> > - if ((arg == F_WRLCK) && ((d_count(dentry) > 1) ||
> > - (atomic_read(&inode->i_count) > 1)))
> > + if ((arg == F_WRLCK) && (atomic_read(&inode->i_readcount) > 1))
> > ret = -EAGAIN;
>
> Alas, i_readcount is not the count of file opens for read, it is the count
> of file opens O_RDONLY, so this is incorrect wrt conflict with other writers.
Whoops, thanks!
> I guess since there is a full smp_mb() before this check, then you
> can check (i_readcount + i_writecount) > 1 || (i_writecount < 0)
>
> You can also check if caller itself is O_RDONLY to know if self
> count is expect to be in i_readcount or i_writecount, but not sure
> it is worth the trouble.
I don't know, it still looks reasonable. I'll fool around with it.
--b.
next prev parent reply other threads:[~2019-02-15 20:09 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-08 11:20 Better interop for NFS/SMB file share mode/reservation Amir Goldstein
2019-02-08 13:10 ` Jeff Layton
2019-02-08 14:45 ` Amir Goldstein
2019-02-08 15:50 ` J. Bruce Fields
2019-02-08 20:02 ` Amir Goldstein
2019-02-08 20:16 ` J. Bruce Fields
2019-02-08 20:31 ` Amir Goldstein
2019-02-14 20:51 ` J. Bruce Fields
2019-02-15 7:31 ` Amir Goldstein
2019-02-15 20:09 ` J. Bruce Fields [this message]
2019-02-08 22:12 ` Jeremy Allison
2019-02-09 4:04 ` Amir Goldstein
2019-02-14 21:06 ` J. Bruce Fields
2019-03-05 21:47 ` J. Bruce Fields
2019-03-06 7:09 ` Amir Goldstein
2019-03-06 15:17 ` J. Bruce Fields
2019-03-06 15:37 ` [NFS-Ganesha-Devel] " Frank Filz
2019-03-08 21:38 ` 'J. Bruce Fields'
2019-03-08 21:53 ` Frank Filz
2019-03-06 15:11 ` J. Bruce Fields
2019-03-06 20:31 ` Jeff Layton
2019-03-06 21:07 ` Jeremy Allison
2019-03-06 21:25 ` Ralph Böhme
2019-03-07 11:03 ` Stefan Metzmacher
2019-03-07 16:47 ` Simo
2019-04-25 18:11 ` Amir Goldstein
2019-03-06 21:55 ` Jeff Layton
2019-02-08 16:03 ` Jeff Layton
2019-02-08 16:28 ` Jeffrey Layton
[not found] ` <CAOQ4uxgQsRaEOxz1aYzP1_1fzRpQbOm2-wuzG=ABAphPB=7Mxg@mail.gmail.com>
[not found] ` <20190426140023.GB25827@fieldses.org>
[not found] ` <CAOQ4uxhuxoEsoBbvenJ8eLGstPc4AH-msrxDC-tBFRhvDxRSNg@mail.gmail.com>
[not found] ` <20190426145006.GD25827@fieldses.org>
[not found] ` <e69d149c80187b84833fec369ad8a51247871f26.camel@kernel.org>
2019-04-27 20:16 ` Amir Goldstein
2019-04-28 12:09 ` Jeff Layton
2019-04-28 13:45 ` Amir Goldstein
2019-04-28 15:06 ` Trond Myklebust
2019-04-28 22:00 ` Amir Goldstein
2019-04-28 22:08 ` Trond Myklebust
2019-04-28 22:33 ` Amir Goldstein
2019-04-29 0:57 ` Trond Myklebust
2019-04-29 11:42 ` Amir Goldstein
2019-04-29 13:10 ` Trond Myklebust
2019-04-29 20:29 ` Jeff Layton
2019-04-29 22:33 ` Pavel Shilovskiy
2019-04-30 0:31 ` Amir Goldstein
2019-04-30 8:12 ` Uri Simchoni
2019-04-30 9:22 ` Amir Goldstein
2019-02-11 5:31 ` ronnie sahlberg
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=20190215200938.GC22354@fieldses.org \
--to=bfields@fieldses.org \
--cc=Volker.Lendecke@sernet.de \
--cc=amir73il@gmail.com \
--cc=jlayton@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=piastryyy@gmail.com \
--cc=samba-technical@lists.samba.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 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).