On Thu, 2013-05-02 at 14:31 -0400, Steve Dickson wrote:
> On 01/05/13 14:59, Myklebust, Trond wrote:
> >> diff --git a/include/linux/nfs_xdr.h b/include/linux/nfs_xdr.h
> >> > index 9f2dba3..4d2fdf6 100644
> >> > --- a/include/linux/nfs_xdr.h
> >> > +++ b/include/linux/nfs_xdr.h
> >> > @@ -351,6 +351,7 @@ struct nfs_openargs {
> >> > const u32 * bitmask;
> >> > const u32 * open_bitmap;
> >> > __u32 claim;
> >> > + const struct nfs4_label *label;
> >> > };
> >> >
> >> > struct nfs_openres {
> >> > @@ -360,6 +361,7 @@ struct nfs_openres {
> >> > struct nfs4_change_info cinfo;
> >> > __u32 rflags;
> >> > struct nfs_fattr * f_attr;
> >> > + struct nfs4_label *f_label;
> >> > struct nfs_seqid * seqid;
> >> > const struct nfs_server *server;
> >> > fmode_t delegation_type;
> >> > @@ -404,6 +406,7 @@ struct nfs_closeres {
> >> > struct nfs4_sequence_res seq_res;
> >> > nfs4_stateid stateid;
> >> > struct nfs_fattr * fattr;
> >> > + struct nfs4_label *label;
> >> > struct nfs_seqid * seqid;
> >> > const struct nfs_server *server;
> >> > };
> >> > @@ -477,6 +480,7 @@ struct nfs4_delegreturnargs {
> >> > struct nfs4_delegreturnres {
> >> > struct nfs4_sequence_res seq_res;
> >> > struct nfs_fattr * fattr;
> >> > + struct nfs4_label *label;
> >> > const struct nfs_server *server;
> >> > };
> >> >
> >> > @@ -497,6 +501,7 @@ struct nfs_readargs {
> >> > struct nfs_readres {
> >> > struct nfs4_sequence_res seq_res;
> >> > struct nfs_fattr * fattr;
> >> > + struct nfs4_label *label;
> > Why do we need to check labels on close, delegreturn, read, remove,
> > rename, etc? Do any of those operations cause our cached labels to
> > change?
> I was not around then this decision was made... Maybe some of the
> security people can address that....
>
> What operation do you think they are needed for?
I would assume that they are only needed for the operations covered by
nfs_atomic_open(), nfs_lookup(), nfs_revalidate_inode() and, of course,
for nfs4_set_security_label().
All other cases are just opportunistic refreshes of the cache, which we
have seen previously can have a nasty impact on NFSv4 performance.
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@xxxxxxxxxx
www.netapp.com
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
