From: "Aneesh Kumar K. V" <aneesh.kumar@linux.vnet.ibm.com>
To: Trond Myklebust <trond.myklebust@netapp.com>
Cc: linux-nfs@vger.kernel.org
Subject: Re: NFSv4 ACL set and inode attribute cache
Date: Mon, 29 Nov 2010 15:46:20 +0530 [thread overview]
Message-ID: <m3zkssjuyz.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <m31v6rrrfr.fsf@linux.vnet.ibm.com>
On Fri, 12 Nov 2010 11:53:20 +0530, "Aneesh Kumar K. V" <aneesh.kumar@linux.vnet.ibm.com> wrote:
> On Thu, 11 Nov 2010 00:21:27 +0530, "Aneesh Kumar K. V" <aneesh.kumar@linux.vnet.ibm.com> wrote:
> > On Wed, 10 Nov 2010 23:31:31 +0530, Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> wrote:
> > >
> > > Hi,
> > >
> > > I guess we are not marking the inode attribute as invalid when we set
> > > the ACL value. For ex:
> > >
> > > /d# mkdir sub3
> > > /d# ls -dl sub3
> > > drwxr-xr-x 2 root root 4096 Nov 10 17:56 sub3
> > > /d# nfs4_setfacl -s A:fd:EVERYONE@:rwax sub3
> > > /d# ls -dl sub3
> > > drwxr-xr-x 2 root root 4096 Nov 10 17:56 sub3
> > > /d#
> > >
> > >
> > > On the server i have the mode bits as
> > > /d# ls -dl sub3
> > > drwxrwxrwx 2 root root 4096 Nov 10 17:56 sub3
> > > /d#
> >
> > We also have similar issue other way round. ie setting the mode bits
> > don't result in ACL values being invalidated. But a second request get
> > the right value of ACL as show below.
> >
> > /d# nfs4_getfacl x
> > A::OWNER@:rw
> > A::GROUP@:rw
> > A::EVERYONE@:r
> > /d# chmod 600 x
> > /d# nfs4_getfacl x
> > A::OWNER@:rw
> > A::GROUP@:rw
> > A::EVERYONE@:r
> > /d#
> >
> > Expected value is
> >
> > /d# nfs4_getfacl x
> > A::OWNER@:rw
> >
>
> The below patch fix the problem for me. If this is the right way
> to fix, I can send a proper patch with commit message and s-o-b.
>
> diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
> index 0f24cdf..666a48b 100644
> --- a/fs/nfs/nfs4proc.c
> +++ b/fs/nfs/nfs4proc.c
> @@ -3359,6 +3359,8 @@ static ssize_t nfs4_proc_get_acl(struct inode *inode, void *buf, size_t buflen)
> ret = nfs_revalidate_inode(server, inode);
> if (ret < 0)
> return ret;
> + if (NFS_I(inode)->cache_validity & NFS_INO_INVALID_ACL)
> + nfs_zap_acl_cache(inode);
> ret = nfs4_read_cached_acl(inode, buf, buflen);
> if (ret != -ENOENT)
> return ret;
> @@ -3387,6 +3389,11 @@ static int __nfs4_proc_set_acl(struct inode *inode, const void *buf, size_t bufl
> nfs_inode_return_delegation(inode);
> buf_to_pages(buf, buflen, arg.acl_pages, &arg.acl_pgbase);
> ret = nfs4_call_sync(server, &msg, &arg, &res, 1);
> + /*
> + * Acl update can result in inode attribute update.
> + * so mark the attribute cache invalid.
> + */
> + NFS_I(inode)->cache_validity |= NFS_INO_INVALID_ATTR;
> nfs_access_zap_cache(inode);
> nfs_zap_acl_cache(inode);
> return ret;
Any update on this ? Another option i figured out today is to make sure
we add FATTR4_WORD0_ACL in nfs4_fattr_bitmap for fetching the modified
acl value on mode update. Similarly setfacl can be compounded with the
getattr request.
-aneesh
next prev parent reply other threads:[~2010-11-29 10:16 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-10 18:01 NFSv4 ACL set and inode attribute cache Aneesh Kumar K.V
2010-11-10 18:51 ` Aneesh Kumar K. V
2010-11-10 20:31 ` J. Bruce Fields
2010-11-12 6:23 ` Aneesh Kumar K. V
2010-11-29 10:16 ` Aneesh Kumar K. V [this message]
2010-11-29 20:13 ` Trond Myklebust
2010-11-30 18:03 ` Aneesh Kumar K. V
2010-11-30 18:38 ` J. Bruce Fields
2010-11-30 18:40 ` Trond Myklebust
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=m3zkssjuyz.fsf@linux.vnet.ibm.com \
--to=aneesh.kumar@linux.vnet.ibm.com \
--cc=linux-nfs@vger.kernel.org \
--cc=trond.myklebust@netapp.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 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.