open by handle support for NFS V2

open by handle support for NFS V2

[Christoph Hellwig]

Hi all,

this resurrects parts of an old series to add open by handle support to
NFS.  The prime intent here is to support the actual open by handle
ioctls, although it will also allow very crude re-exporting.  Without
the other patches from Jeff's series that re-exporting will suck badly
though.

Changes since V1:
 - rebased on top of the nfs op constifycation (as merged in the nfsd tree)

[PATCH 1/4] nfs: replace d_add with d_splice_alias in atomic_open

[Christoph Hellwig]

From: Peng Tao <tao.peng@primarydata.com>

It's a trival change but follows knfsd export document that asks
for d_splice_alias during lookup.

Signed-off-by: Peng Tao <tao.peng@primarydata.com>
---
 fs/nfs/dir.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c
index 32ccd7754f8a..0296c06dcdc5 100644
--- a/fs/nfs/dir.c
+++ b/fs/nfs/dir.c
@@ -1512,7 +1512,7 @@ int nfs_atomic_open(struct inode *dir, struct dentry *dentry,
 		d_drop(dentry);
 		switch (err) {
 		case -ENOENT:
-			d_add(dentry, NULL);
+			d_splice_alias(NULL, dentry);
 			nfs_set_verifier(dentry, nfs_save_change_attribute(dir));
 			break;
 		case -EISDIR:
-- 
2.11.0

[PATCH 2/4] nfs: add a nfs_ilookup helper

[Christoph Hellwig]

From: Peng Tao <tao.peng@primarydata.com>

This helper will allow to find an existing NFS inode by the file handle
and fattr.

Signed-off-by: Peng Tao <tao.peng@primarydata.com>
[hch: split from a larger patch]
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 fs/nfs/inode.c         | 22 ++++++++++++++++++++++
 include/linux/nfs_fs.h |  1 +
 2 files changed, 23 insertions(+)

diff --git a/fs/nfs/inode.c b/fs/nfs/inode.c
index 1de93ba78dc9..a84eab1a18a7 100644
--- a/fs/nfs/inode.c
+++ b/fs/nfs/inode.c
@@ -386,6 +386,28 @@ void nfs_setsecurity(struct inode *inode, struct nfs_fattr *fattr,
 #endif
 EXPORT_SYMBOL_GPL(nfs_setsecurity);
 
+/* Search for inode identified by fh, fileid and i_mode in inode cache. */
+struct inode *
+nfs_ilookup(struct super_block *sb, struct nfs_fattr *fattr, struct nfs_fh *fh)
+{
+	struct nfs_find_desc desc = {
+		.fh	= fh,
+		.fattr	= fattr,
+	};
+	struct inode *inode;
+	unsigned long hash;
+
+	if (!(fattr->valid & NFS_ATTR_FATTR_FILEID) ||
+	    !(fattr->valid & NFS_ATTR_FATTR_TYPE))
+		return NULL;
+
+	hash = nfs_fattr_to_ino_t(fattr);
+	inode = ilookup5(sb, hash, nfs_find_actor, &desc);
+
+	dprintk("%s: returning %p\n", __func__, inode);
+	return inode;
+}
+
 /*
  * This is our front-end to iget that looks up inodes by file handle
  * instead of inode number.
diff --git a/include/linux/nfs_fs.h b/include/linux/nfs_fs.h
index bb0eb2c9acca..e52cc55ac300 100644
--- a/include/linux/nfs_fs.h
+++ b/include/linux/nfs_fs.h
@@ -332,6 +332,7 @@ extern void nfs_zap_caches(struct inode *);
 extern void nfs_invalidate_atime(struct inode *);
 extern struct inode *nfs_fhget(struct super_block *, struct nfs_fh *,
 				struct nfs_fattr *, struct nfs4_label *);
+struct inode *nfs_ilookup(struct super_block *sb, struct nfs_fattr *, struct nfs_fh *);
 extern int nfs_refresh_inode(struct inode *, struct nfs_fattr *);
 extern int nfs_post_op_update_inode(struct inode *inode, struct nfs_fattr *fattr);
 extern int nfs_post_op_update_inode_force_wcc(struct inode *inode, struct nfs_fattr *fattr);
-- 
2.11.0

[PATCH 3/4] nfs4: add NFSv4 LOOKUPP handlers

[Christoph Hellwig]

From: Jeff Layton <jeff.layton@primarydata.com>

This will be needed in order to implement the get_parent export op
for nfsd.

Signed-off-by: Jeff Layton <jeff.layton@primarydata.com>
---
 fs/nfs/nfs4proc.c       | 49 ++++++++++++++++++++++++++++++++
 fs/nfs/nfs4trace.h      | 29 +++++++++++++++++++
 fs/nfs/nfs4xdr.c        | 75 +++++++++++++++++++++++++++++++++++++++++++++++++
 include/linux/nfs4.h    |  1 +
 include/linux/nfs_xdr.h | 17 ++++++++++-
 5 files changed, 170 insertions(+), 1 deletion(-)

diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
index c08c46a3b8cd..6fd9eee8e4ee 100644
--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
@@ -3802,6 +3802,54 @@ nfs4_proc_lookup_mountpoint(struct inode *dir, const struct qstr *name,
 	return (client == NFS_CLIENT(dir)) ? rpc_clone_client(client) : client;
 }
 
+static int _nfs4_proc_lookupp(struct inode *inode,
+		struct nfs_fh *fhandle, struct nfs_fattr *fattr,
+		struct nfs4_label *label)
+{
+	struct rpc_clnt *clnt = NFS_CLIENT(inode);
+	struct nfs_server *server = NFS_SERVER(inode);
+	int		       status;
+	struct nfs4_lookupp_arg args = {
+		.bitmask = server->attr_bitmask,
+		.fh = NFS_FH(inode),
+	};
+	struct nfs4_lookupp_res res = {
+		.server = server,
+		.fattr = fattr,
+		.label = label,
+		.fh = fhandle,
+	};
+	struct rpc_message msg = {
+		.rpc_proc = &nfs4_procedures[NFSPROC4_CLNT_LOOKUPP],
+		.rpc_argp = &args,
+		.rpc_resp = &res,
+	};
+
+	args.bitmask = nfs4_bitmask(server, label);
+
+	nfs_fattr_init(fattr);
+
+	dprintk("NFS call  lookupp ino=0x%lx\n", inode->i_ino);
+	status = nfs4_call_sync(clnt, server, &msg, &args.seq_args,
+				&res.seq_res, 0);
+	dprintk("NFS reply lookupp: %d\n", status);
+	return status;
+}
+
+static int nfs4_proc_lookupp(struct inode *inode, struct nfs_fh *fhandle,
+			     struct nfs_fattr *fattr, struct nfs4_label *label)
+{
+	struct nfs4_exception exception = { };
+	int err;
+	do {
+		err = _nfs4_proc_lookupp(inode, fhandle, fattr, label);
+		trace_nfs4_lookupp(inode, err);
+		err = nfs4_handle_exception(NFS_SERVER(inode), err,
+				&exception);
+	} while (exception.retry);
+	return err;
+}
+
 static int _nfs4_proc_access(struct inode *inode, struct nfs_access_entry *entry)
 {
 	struct nfs_server *server = NFS_SERVER(inode);
@@ -9312,6 +9360,7 @@ const struct nfs_rpc_ops nfs_v4_clientops = {
 	.getattr	= nfs4_proc_getattr,
 	.setattr	= nfs4_proc_setattr,
 	.lookup		= nfs4_proc_lookup,
+	.lookupp	= nfs4_proc_lookupp,
 	.access		= nfs4_proc_access,
 	.readlink	= nfs4_proc_readlink,
 	.create		= nfs4_proc_create,
diff --git a/fs/nfs/nfs4trace.h b/fs/nfs/nfs4trace.h
index 845d0eadefc9..be1da19c65d6 100644
--- a/fs/nfs/nfs4trace.h
+++ b/fs/nfs/nfs4trace.h
@@ -891,6 +891,35 @@ DEFINE_NFS4_LOOKUP_EVENT(nfs4_remove);
 DEFINE_NFS4_LOOKUP_EVENT(nfs4_get_fs_locations);
 DEFINE_NFS4_LOOKUP_EVENT(nfs4_secinfo);
 
+TRACE_EVENT(nfs4_lookupp,
+		TP_PROTO(
+			const struct inode *inode,
+			int error
+		),
+
+		TP_ARGS(inode, error),
+
+		TP_STRUCT__entry(
+			__field(dev_t, dev)
+			__field(u64, ino)
+			__field(int, error)
+		),
+
+		TP_fast_assign(
+			__entry->dev = inode->i_sb->s_dev;
+			__entry->ino = NFS_FILEID(inode);
+			__entry->error = error;
+		),
+
+		TP_printk(
+			"error=%d (%s) inode=%02x:%02x:%llu",
+			__entry->error,
+			show_nfsv4_errors(__entry->error),
+			MAJOR(__entry->dev), MINOR(__entry->dev),
+			(unsigned long long)__entry->ino
+		)
+);
+
 TRACE_EVENT(nfs4_rename,
 		TP_PROTO(
 			const struct inode *olddir,
diff --git a/fs/nfs/nfs4xdr.c b/fs/nfs/nfs4xdr.c
index 0f1f290c97cd..ad50ae499b6b 100644
--- a/fs/nfs/nfs4xdr.c
+++ b/fs/nfs/nfs4xdr.c
@@ -159,6 +159,8 @@ static int nfs4_stat_to_errno(int);
 				(op_decode_hdr_maxsz)
 #define encode_lookup_maxsz	(op_encode_hdr_maxsz + nfs4_name_maxsz)
 #define decode_lookup_maxsz	(op_decode_hdr_maxsz)
+#define encode_lookupp_maxsz	(op_encode_hdr_maxsz)
+#define decode_lookupp_maxsz	(op_decode_hdr_maxsz)
 #define encode_share_access_maxsz \
 				(2)
 #define encode_createmode_maxsz	(1 + encode_attrs_maxsz + encode_verifier_maxsz)
@@ -618,6 +620,18 @@ static int nfs4_stat_to_errno(int);
 				decode_lookup_maxsz + \
 				decode_getattr_maxsz + \
 				decode_getfh_maxsz)
+#define NFS4_enc_lookupp_sz	(compound_encode_hdr_maxsz + \
+				encode_sequence_maxsz + \
+				encode_putfh_maxsz + \
+				encode_lookupp_maxsz + \
+				encode_getattr_maxsz + \
+				encode_getfh_maxsz)
+#define NFS4_dec_lookupp_sz	(compound_decode_hdr_maxsz + \
+				decode_sequence_maxsz + \
+				decode_putfh_maxsz + \
+				decode_lookupp_maxsz + \
+				decode_getattr_maxsz + \
+				decode_getfh_maxsz)
 #define NFS4_enc_lookup_root_sz (compound_encode_hdr_maxsz + \
 				encode_sequence_maxsz + \
 				encode_putrootfh_maxsz + \
@@ -1368,6 +1382,11 @@ static void encode_lookup(struct xdr_stream *xdr, const struct qstr *name, struc
 	encode_string(xdr, name->len, name->name);
 }
 
+static void encode_lookupp(struct xdr_stream *xdr, struct compound_hdr *hdr)
+{
+	encode_op_hdr(xdr, OP_LOOKUPP, decode_lookupp_maxsz, hdr);
+}
+
 static void encode_share_access(struct xdr_stream *xdr, u32 share_access)
 {
 	__be32 *p;
@@ -2123,6 +2142,26 @@ static void nfs4_xdr_enc_lookup(struct rpc_rqst *req, struct xdr_stream *xdr,
 }
 
 /*
+ * Encode LOOKUPP request
+ */
+static void nfs4_xdr_enc_lookupp(struct rpc_rqst *req, struct xdr_stream *xdr,
+		const void *data)
+{
+	const struct nfs4_lookupp_arg *args = data;
+	struct compound_hdr hdr = {
+		.minorversion = nfs4_xdr_minorversion(&args->seq_args),
+	};
+
+	encode_compound_hdr(xdr, req, &hdr);
+	encode_sequence(xdr, &args->seq_args, &hdr);
+	encode_putfh(xdr, args->fh, &hdr);
+	encode_lookupp(xdr, &hdr);
+	encode_getfh(xdr, &hdr);
+	encode_getfattr(xdr, args->bitmask, &hdr);
+	encode_nops(&hdr);
+}
+
+/*
  * Encode LOOKUP_ROOT request
  */
 static void nfs4_xdr_enc_lookup_root(struct rpc_rqst *req,
@@ -5058,6 +5097,11 @@ static int decode_lookup(struct xdr_stream *xdr)
 	return decode_op_hdr(xdr, OP_LOOKUP);
 }
 
+static int decode_lookupp(struct xdr_stream *xdr)
+{
+	return decode_op_hdr(xdr, OP_LOOKUPP);
+}
+
 /* This is too sick! */
 static int decode_space_limit(struct xdr_stream *xdr,
 		unsigned long *pagemod_limit)
@@ -6238,6 +6282,36 @@ static int nfs4_xdr_dec_lookup(struct rpc_rqst *rqstp, struct xdr_stream *xdr,
 }
 
 /*
+ * Decode LOOKUPP response
+ */
+static int nfs4_xdr_dec_lookupp(struct rpc_rqst *rqstp, struct xdr_stream *xdr,
+		void *data)
+{
+	struct nfs4_lookupp_res *res = data;
+	struct compound_hdr hdr;
+	int status;
+
+	status = decode_compound_hdr(xdr, &hdr);
+	if (status)
+		goto out;
+	status = decode_sequence(xdr, &res->seq_res, rqstp);
+	if (status)
+		goto out;
+	status = decode_putfh(xdr);
+	if (status)
+		goto out;
+	status = decode_lookupp(xdr);
+	if (status)
+		goto out;
+	status = decode_getfh(xdr, res->fh);
+	if (status)
+		goto out;
+	status = decode_getfattr_label(xdr, res->fattr, res->label, res->server);
+out:
+	return status;
+}
+
+/*
  * Decode LOOKUP_ROOT response
  */
 static int nfs4_xdr_dec_lookup_root(struct rpc_rqst *rqstp,
@@ -7614,6 +7688,7 @@ const struct rpc_procinfo nfs4_procedures[] = {
 	PROC(ACCESS,		enc_access,		dec_access),
 	PROC(GETATTR,		enc_getattr,		dec_getattr),
 	PROC(LOOKUP,		enc_lookup,		dec_lookup),
+	PROC(LOOKUPP,		enc_lookupp,		dec_lookupp),
 	PROC(LOOKUP_ROOT,	enc_lookup_root,	dec_lookup_root),
 	PROC(REMOVE,		enc_remove,		dec_remove),
 	PROC(RENAME,		enc_rename,		dec_rename),
diff --git a/include/linux/nfs4.h b/include/linux/nfs4.h
index 1b1ca04820a3..47239c336688 100644
--- a/include/linux/nfs4.h
+++ b/include/linux/nfs4.h
@@ -479,6 +479,7 @@ enum {
 	NFSPROC4_CLNT_ACCESS,
 	NFSPROC4_CLNT_GETATTR,
 	NFSPROC4_CLNT_LOOKUP,
+	NFSPROC4_CLNT_LOOKUPP,
 	NFSPROC4_CLNT_LOOKUP_ROOT,
 	NFSPROC4_CLNT_REMOVE,
 	NFSPROC4_CLNT_RENAME,
diff --git a/include/linux/nfs_xdr.h b/include/linux/nfs_xdr.h
index b28c83475ee8..7a664a5fcc25 100644
--- a/include/linux/nfs_xdr.h
+++ b/include/linux/nfs_xdr.h
@@ -1012,7 +1012,6 @@ struct nfs4_link_res {
 	struct nfs_fattr *		dir_attr;
 };
 
-
 struct nfs4_lookup_arg {
 	struct nfs4_sequence_args	seq_args;
 	const struct nfs_fh *		dir_fh;
@@ -1028,6 +1027,20 @@ struct nfs4_lookup_res {
 	struct nfs4_label		*label;
 };
 
+struct nfs4_lookupp_arg {
+	struct nfs4_sequence_args	seq_args;
+	const struct nfs_fh		*fh;
+	const u32			*bitmask;
+};
+
+struct nfs4_lookupp_res {
+	struct nfs4_sequence_res	seq_res;
+	const struct nfs_server		*server;
+	struct nfs_fattr		*fattr;
+	struct nfs_fh			*fh;
+	struct nfs4_label		*label;
+};
+
 struct nfs4_lookup_root_arg {
 	struct nfs4_sequence_args	seq_args;
 	const u32 *			bitmask;
@@ -1567,6 +1580,8 @@ struct nfs_rpc_ops {
 	int	(*lookup)  (struct inode *, const struct qstr *,
 			    struct nfs_fh *, struct nfs_fattr *,
 			    struct nfs4_label *);
+	int	(*lookupp) (struct inode *, struct nfs_fh *,
+			    struct nfs_fattr *, struct nfs4_label *);
 	int	(*access)  (struct inode *, struct nfs_access_entry *);
 	int	(*readlink)(struct inode *, struct page *, unsigned int,
 			    unsigned int);
-- 
2.11.0

[PATCH 4/4] nfs: add export operations

[Christoph Hellwig]

From: Peng Tao <tao.peng@primarydata.com>

This support for opening files on NFS by file handle, both through the
open_by_handle syscall, and for re-exporting NFS (for example using a
different version).  The support is very basic for now, as each open by
handle will have to do an NFSv4 open operation on the wire.  In the
future this will hopefully be mitigated by an open file cache, as well
as various optimizations in NFS for this specific case.

Signed-off-by: Peng Tao <tao.peng@primarydata.com>
[hch: incorporated various changes, resplit the patches, new changelog]
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 fs/nfs/Makefile   |   2 +-
 fs/nfs/export.c   | 177 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 fs/nfs/internal.h |   2 +
 fs/nfs/super.c    |   2 +
 4 files changed, 182 insertions(+), 1 deletion(-)
 create mode 100644 fs/nfs/export.c

diff --git a/fs/nfs/Makefile b/fs/nfs/Makefile
index 98f4e5728a67..1fb118902d57 100644
--- a/fs/nfs/Makefile
+++ b/fs/nfs/Makefile
@@ -7,7 +7,7 @@ obj-$(CONFIG_NFS_FS) += nfs.o
 CFLAGS_nfstrace.o += -I$(src)
 nfs-y 			:= client.o dir.o file.o getroot.o inode.o super.o \
 			   io.o direct.o pagelist.o read.o symlink.o unlink.o \
-			   write.o namespace.o mount_clnt.o nfstrace.o
+			   write.o namespace.o mount_clnt.o nfstrace.o export.o
 nfs-$(CONFIG_ROOT_NFS)	+= nfsroot.o
 nfs-$(CONFIG_SYSCTL)	+= sysctl.o
 nfs-$(CONFIG_NFS_FSCACHE) += fscache.o fscache-index.o
diff --git a/fs/nfs/export.c b/fs/nfs/export.c
new file mode 100644
index 000000000000..249cb96cc5b5
--- /dev/null
+++ b/fs/nfs/export.c
@@ -0,0 +1,177 @@
+/*
+ * Copyright (c) 2015, Primary Data, Inc. All rights reserved.
+ *
+ * Tao Peng <bergwolf@primarydata.com>
+ */
+#include <linux/dcache.h>
+#include <linux/exportfs.h>
+#include <linux/nfs.h>
+#include <linux/nfs_fs.h>
+
+#include "internal.h"
+#include "nfstrace.h"
+
+#define NFSDBG_FACILITY		NFSDBG_VFS
+
+enum {
+	FILEID_HIGH_OFF = 0,	/* inode fileid high */
+	FILEID_LOW_OFF,		/* inode fileid low */
+	FILE_I_TYPE_OFF,	/* inode type */
+	EMBED_FH_OFF		/* embeded server fh */
+};
+
+
+static struct nfs_fh *nfs_exp_embedfh(__u32 *p)
+{
+	return (struct nfs_fh *)(p + EMBED_FH_OFF);
+}
+
+/*
+ * Let's break subtree checking for now... otherwise we'll have to embed parent fh
+ * but there might not be enough space.
+ */
+static int
+nfs_encode_fh(struct inode *inode, __u32 *p, int *max_len, struct inode *parent)
+{
+	struct nfs_fh *server_fh = NFS_FH(inode);
+	struct nfs_fh *clnt_fh = nfs_exp_embedfh(p);
+	size_t fh_size = offsetof(struct nfs_fh, data) + server_fh->size;
+	int len = EMBED_FH_OFF + XDR_QUADLEN(fh_size);
+
+	dprintk("%s: max fh len %d inode %p parent %p",
+		__func__, *max_len, inode, parent);
+
+	if (*max_len < len || IS_AUTOMOUNT(inode)) {
+		dprintk("%s: fh len %d too small, required %d\n",
+			__func__, *max_len, len);
+		*max_len = len;
+		return FILEID_INVALID;
+	}
+	if (IS_AUTOMOUNT(inode)) {
+		*max_len = FILEID_INVALID;
+		goto out;
+	}
+
+	p[FILEID_HIGH_OFF] = NFS_FILEID(inode) >> 32;
+	p[FILEID_LOW_OFF] = NFS_FILEID(inode);
+	p[FILE_I_TYPE_OFF] = inode->i_mode & S_IFMT;
+	p[len - 1] = 0; /* Padding */
+	nfs_copy_fh(clnt_fh, server_fh);
+	*max_len = len;
+out:
+	dprintk("%s: result fh fileid %llu mode %u size %d\n",
+		__func__, NFS_FILEID(inode), inode->i_mode, *max_len);
+	return *max_len;
+}
+
+static struct dentry *
+nfs_fh_to_dentry(struct super_block *sb, struct fid *fid,
+		 int fh_len, int fh_type)
+{
+	struct nfs4_label *label = NULL;
+	struct nfs_fattr *fattr = NULL;
+	struct nfs_fh *server_fh = nfs_exp_embedfh(fid->raw);
+	size_t fh_size = offsetof(struct nfs_fh, data) + server_fh->size;
+	const struct nfs_rpc_ops *rpc_ops;
+	struct dentry *dentry;
+	struct inode *inode;
+	int len = EMBED_FH_OFF + XDR_QUADLEN(fh_size);
+	u32 *p = fid->raw;
+	int ret;
+
+	/* NULL translates to ESTALE */
+	if (fh_len < len || fh_type != len)
+		return NULL;
+
+	fattr = nfs_alloc_fattr();
+	if (fattr == NULL) {
+		dentry = ERR_PTR(-ENOMEM);
+		goto out;
+	}
+
+	fattr->fileid = ((u64)p[FILEID_HIGH_OFF] << 32) + p[FILEID_LOW_OFF];
+	fattr->mode = p[FILE_I_TYPE_OFF];
+	fattr->valid |= NFS_ATTR_FATTR_FILEID | NFS_ATTR_FATTR_TYPE;
+
+	dprintk("%s: fileid %llu mode %d\n", __func__, fattr->fileid, fattr->mode);
+
+	inode = nfs_ilookup(sb, fattr, server_fh);
+	if (inode)
+		goto out_found;
+
+	label = nfs4_label_alloc(NFS_SB(sb), GFP_KERNEL);
+	if (IS_ERR(label)) {
+		dentry = ERR_CAST(label);
+		goto out_free_fattr;
+	}
+
+	rpc_ops = NFS_SB(sb)->nfs_client->rpc_ops;
+	ret = rpc_ops->getattr(NFS_SB(sb), server_fh, fattr, label);
+	if (ret) {
+		dprintk("%s: getattr failed %d\n", __func__, ret);
+		dentry = ERR_PTR(ret);
+		goto out_free_label;
+	}
+
+	inode = nfs_fhget(sb, server_fh, fattr, label);
+
+out_found:
+	dentry = d_obtain_alias(inode);
+
+out_free_label:
+	nfs4_label_free(label);
+out_free_fattr:
+	nfs_free_fattr(fattr);
+out:
+	return dentry;
+}
+
+static struct dentry *
+nfs_get_parent(struct dentry *dentry)
+{
+	int ret;
+	struct inode *inode = d_inode(dentry), *pinode;
+	struct super_block *sb = inode->i_sb;
+	struct nfs_server *server = NFS_SB(sb);
+	struct nfs_fattr *fattr = NULL;
+	struct nfs4_label *label = NULL;
+	struct dentry *parent;
+	struct nfs_rpc_ops const *ops = server->nfs_client->rpc_ops;
+	struct nfs_fh fh;
+
+	if (!ops->lookupp)
+		return ERR_PTR(-EACCES);
+
+	fattr = nfs_alloc_fattr();
+	if (fattr == NULL) {
+		parent = ERR_PTR(-ENOMEM);
+		goto out;
+	}
+
+	label = nfs4_label_alloc(server, GFP_KERNEL);
+	if (IS_ERR(label)) {
+		parent = ERR_CAST(label);
+		goto out_free_fattr;
+	}
+
+	ret = ops->lookupp(inode, &fh, fattr, label);
+	if (ret) {
+		parent = ERR_PTR(ret);
+		goto out_free_label;
+	}
+
+	pinode = nfs_fhget(sb, &fh, fattr, label);
+	parent = d_obtain_alias(pinode);
+out_free_label:
+	nfs4_label_free(label);
+out_free_fattr:
+	nfs_free_fattr(fattr);
+out:
+	return parent;
+}
+
+const struct export_operations nfs_export_ops = {
+	.encode_fh = nfs_encode_fh,
+	.fh_to_dentry = nfs_fh_to_dentry,
+	.get_parent = nfs_get_parent,
+};
diff --git a/fs/nfs/internal.h b/fs/nfs/internal.h
index 9976d8498cf3..35230b1b7a74 100644
--- a/fs/nfs/internal.h
+++ b/fs/nfs/internal.h
@@ -10,6 +10,8 @@
 
 #define NFS_MS_MASK (MS_RDONLY|MS_NOSUID|MS_NODEV|MS_NOEXEC|MS_SYNCHRONOUS)
 
+extern const struct export_operations nfs_export_ops;
+
 struct nfs_string;
 
 /* Maximum number of readahead requests
diff --git a/fs/nfs/super.c b/fs/nfs/super.c
index 2f3822a4a7d5..508ad3a1cf4e 100644
--- a/fs/nfs/super.c
+++ b/fs/nfs/super.c
@@ -2339,6 +2339,7 @@ void nfs_fill_super(struct super_block *sb, struct nfs_mount_info *mount_info)
 		 */
 		sb->s_flags |= MS_POSIXACL;
 		sb->s_time_gran = 1;
+		sb->s_export_op = &nfs_export_ops;
 	}
 
  	nfs_initialise_sb(sb);
@@ -2359,6 +2360,7 @@ void nfs_clone_super(struct super_block *sb, struct nfs_mount_info *mount_info)
 	sb->s_xattr = old_sb->s_xattr;
 	sb->s_op = old_sb->s_op;
 	sb->s_time_gran = 1;
+	sb->s_export_op = old_sb->s_export_op;
 
 	if (server->nfs_client->rpc_ops->version != 2) {
 		/* The VFS shouldn't apply the umask to mode bits. We will do
-- 
2.11.0

Re: open by handle support for NFS V2

[J. Bruce Fields]

On Thu, Jun 29, 2017 at 06:34:49AM -0700, Christoph Hellwig wrote:
> this resurrects parts of an old series to add open by handle support to
> NFS.  The prime intent here is to support the actual open by handle
> ioctls, although it will also allow very crude re-exporting.  Without
> the other patches from Jeff's series that re-exporting will suck badly
> though.

Why do we want this?

Any re-export support is going to have some major limitations.  (No file
locking, and re-export of NFSv4 probably not possible?)

Last I heard the only motivation was extremely specific to Primary
Data's setup.  I'm happy to help them, but I think we need *some*
evidence this will be useful to upstream users.

--b.

Re: open by handle support for NFS V2

[Trond Myklebust]

T24gVGh1LCAyMDE3LTA2LTI5IGF0IDExOjQ2IC0wNDAwLCBKLiBCcnVjZSBGaWVsZHMgd3JvdGU6
DQo+IE9uIFRodSwgSnVuIDI5LCAyMDE3IGF0IDA2OjM0OjQ5QU0gLTA3MDAsIENocmlzdG9waCBI
ZWxsd2lnIHdyb3RlOg0KPiA+IHRoaXMgcmVzdXJyZWN0cyBwYXJ0cyBvZiBhbiBvbGQgc2VyaWVz
IHRvIGFkZCBvcGVuIGJ5IGhhbmRsZQ0KPiA+IHN1cHBvcnQgdG8NCj4gPiBORlMuwqDCoFRoZSBw
cmltZSBpbnRlbnQgaGVyZSBpcyB0byBzdXBwb3J0IHRoZSBhY3R1YWwgb3BlbiBieSBoYW5kbGUN
Cj4gPiBpb2N0bHMsIGFsdGhvdWdoIGl0IHdpbGwgYWxzbyBhbGxvdyB2ZXJ5IGNydWRlIHJlLQ0K
PiA+IGV4cG9ydGluZy7CoMKgV2l0aG91dA0KPiA+IHRoZSBvdGhlciBwYXRjaGVzIGZyb20gSmVm
ZidzIHNlcmllcyB0aGF0IHJlLWV4cG9ydGluZyB3aWxsIHN1Y2sNCj4gPiBiYWRseQ0KPiA+IHRo
b3VnaC4NCj4gDQo+IFdoeSBkbyB3ZSB3YW50IHRoaXM/DQo+IA0KPiBBbnkgcmUtZXhwb3J0IHN1
cHBvcnQgaXMgZ29pbmcgdG8gaGF2ZSBzb21lIG1ham9yIGxpbWl0YXRpb25zLsKgwqAoTm8NCj4g
ZmlsZQ0KPiBsb2NraW5nLCBhbmQgcmUtZXhwb3J0IG9mIE5GU3Y0IHByb2JhYmx5IG5vdCBwb3Nz
aWJsZT8pDQo+IA0KPiBMYXN0IEkgaGVhcmQgdGhlIG9ubHkgbW90aXZhdGlvbiB3YXMgZXh0cmVt
ZWx5IHNwZWNpZmljIHRvIFByaW1hcnkNCj4gRGF0YSdzIHNldHVwLsKgwqBJJ20gaGFwcHkgdG8g
aGVscCB0aGVtLCBidXQgSSB0aGluayB3ZSBuZWVkICpzb21lKg0KPiBldmlkZW5jZSB0aGlzIHdp
bGwgYmUgdXNlZnVsIHRvIHVwc3RyZWFtIHVzZXJzLg0KPiANCg0KVGhlIG1haW4gdXNlIGNhc2Ug
Zm9yIG9wZW4gYnkgZmlsZWhhbmRsZSB3YXMgKGFuZCBzdGlsbCBzaG91bGQgYmUpIHRoZQ0KcHJv
bWlzZSBvZiBiZWluZyBhYmxlIHRvIGRvIHRoZSBzb3J0IG9mIHRyaWNrcyB5b3Ugbm9ybWFsbHkg
YXNzb2NpYXRlDQp3aXRoIG9iamVjdCBzdG9yYWdlIG9uIGEgc3RhbmRhcmQgZmlsZXN5c3RlbS4N
Cg0KSW1hZ2luZSB0aGF0IHlvdSBhcmUgdHJ5aW5nIHRvIGJ1aWxkIGFuIGFwcGxpY2F0aW9uIGZv
ciBpbmRleGluZyBhbmQNCnNlYXJjaGluZyB0aGUgZGF0YSBvbiB5b3VyIHN0b3JhZ2UuIFlvdSBi
YXNpY2FsbHkgd2FudCB0byB0cmF3bCB0aHJvdWdoDQp0aGUgZmlsZXN5c3RlbSBvbiBhIHJlZ3Vs
YXIgYmFzaXMgYW5kIGJ1aWxkIHVwIGEgZGF0YWJhc2Ugb2Yga2V5IHdvcmRzDQphbmQgb3RoZXIg
bWV0YWRhdGEgdG8gdGVsbCB5b3Ugd2hhdCBpcyBpbiB0aGUgZmlsZXMuIEZvciB0aGF0IGtpbmQg
b2YNCmFwcGxpY2F0aW9uLCB0aGUgbmFtZXNwYWNlIGlzIGEgcmVhbCBQSVRBIHRvIGRlYWwgd2l0
aCwgYmVjYXVzZSBmaWxlcw0KZ2V0IHJlbmFtZWQsIG1vdmVkIGFuZCBkZWxldGVkIGFsbCB0aGUg
dGltZTsgc28gaWYgeW91IGNhbiBzdG9yZQ0Kc29tZXRoaW5nIHRoYXQgaXMgaW5kZXBlbmRlbnQg
b2YgdGhlIG5hbWVzcGFjZSBhbmQgdGhhdCB3aWxsIGdpdmUgeW91DQphY2Nlc3MgdG8gdGhlIGZp
bGUgY29udGVudHMsIHRoZW4gd2h5IHdvdWxkbid0IHlvdSBkbyBzbz8gTm9ybWFsbHksDQphcHBs
aWNhdGlvbnMgbGlrZSB0aGF0IHVzZSB0aGUgaW5vZGUgbnVtYmVyLCBidXQgeW91IGNhbid0IG9w
ZW4gYSBmaWxlDQpieSBpbm9kZSBudW1iZXIsIGFuZCB5b3UgaGF2ZSB0aGUgc2FtZSBwcm9ibGVt
cyB3aXRoIGlub2RlIG51bWJlciByZXVzZQ0KdGhhdCBhIE5GUyBzZXJ2ZXIgaGFzLg0KDQpUaGF0
J3MgdGhlIHNvcnQgb2YgdGhpbmcgSSdkIHRoaW5rIHdlIHdhbnQgdG8gYWxsb3cgdGhyb3VnaCBv
cGVuIGJ5DQpmaWxlaGFuZGxlLCBhbmQgSSBzZWUgbm8gcmVhc29uIHdoeSBORlMgc2hvdWxkIGJl
IGV4Y2x1ZGVkIGZyb20gdGhhdA0KdHlwZSBvZiBhcHBsaWNhdGlvbi4NCg0KLS0gDQpUcm9uZCBN
eWtsZWJ1c3QNCkxpbnV4IE5GUyBjbGllbnQgbWFpbnRhaW5lciwgUHJpbWFyeURhdGENCnRyb25k
Lm15a2xlYnVzdEBwcmltYXJ5ZGF0YS5jb20NCg==

Re: open by handle support for NFS V2

[bfields]

On Fri, Jun 30, 2017 at 05:00:59PM +0000, Trond Myklebust wrote:
> The main use case for open by filehandle was (and still should be) the
> promise of being able to do the sort of tricks you normally associate
> with object storage on a standard filesystem.
> 
> Imagine that you are trying to build an application for indexing and
> searching the data on your storage. You basically want to trawl through
> the filesystem on a regular basis and build up a database of key words
> and other metadata to tell you what is in the files. For that kind of
> application, the namespace is a real PITA to deal with, because files
> get renamed, moved and deleted all the time; so if you can store
> something that is independent of the namespace and that will give you
> access to the file contents, then why wouldn't you do so? Normally,
> applications like that use the inode number, but you can't open a file
> by inode number, and you have the same problems with inode number reuse
> that a NFS server has.
> 
> That's the sort of thing I'd think we want to allow through open by
> filehandle, and I see no reason why NFS should be excluded from that
> type of application.

Thanks, that makes sense.

We've had open_by_handle support for most filesystems since 2011, is
there evidence of anyone doing this?

--b.

Re: open by handle support for NFS V2

[Mkrtchyan, Tigran]

----- Original Message -----
> From: "J. Bruce Fields" <bfields@fieldses.org>
> To: "Trond Myklebust" <trondmy@primarydata.com>
> Cc: "Christoph Hellwig" <hch@lst.de>, "Jeff Layton" <jlayton@poochiereds.net>, "linux-nfs" <linux-nfs@vger.kernel.org>,
> "schumaker anna" <schumaker.anna@gmail.com>
> Sent: Friday, June 30, 2017 7:38:18 PM
> Subject: Re: open by handle support for NFS V2

> On Fri, Jun 30, 2017 at 05:00:59PM +0000, Trond Myklebust wrote:
>> The main use case for open by filehandle was (and still should be) the
>> promise of being able to do the sort of tricks you normally associate
>> with object storage on a standard filesystem.
>> 
>> Imagine that you are trying to build an application for indexing and
>> searching the data on your storage. You basically want to trawl through
>> the filesystem on a regular basis and build up a database of key words
>> and other metadata to tell you what is in the files. For that kind of
>> application, the namespace is a real PITA to deal with, because files
>> get renamed, moved and deleted all the time; so if you can store
>> something that is independent of the namespace and that will give you
>> access to the file contents, then why wouldn't you do so? Normally,
>> applications like that use the inode number, but you can't open a file
>> by inode number, and you have the same problems with inode number reuse
>> that a NFS server has.
>> 
>> That's the sort of thing I'd think we want to allow through open by
>> filehandle, and I see no reason why NFS should be excluded from that
>> type of application.
> 
> Thanks, that makes sense.
> 
> We've had open_by_handle support for most filesystems since 2011, is
> there evidence of anyone doing this?


I am pretty sure that nfs-ganesha is using this in one the backend
implementations.

Tigran.

> 
> --b.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: open by handle support for NFS V2

[J. Bruce Fields]

On Sat, Jul 01, 2017 at 11:34:36AM +0200, Mkrtchyan, Tigran wrote:
> 
> 
> ----- Original Message -----
> > From: "J. Bruce Fields" <bfields@fieldses.org>
> > To: "Trond Myklebust" <trondmy@primarydata.com>
> > Cc: "Christoph Hellwig" <hch@lst.de>, "Jeff Layton" <jlayton@poochiereds.net>, "linux-nfs" <linux-nfs@vger.kernel.org>,
> > "schumaker anna" <schumaker.anna@gmail.com>
> > Sent: Friday, June 30, 2017 7:38:18 PM
> > Subject: Re: open by handle support for NFS V2
> 
> > On Fri, Jun 30, 2017 at 05:00:59PM +0000, Trond Myklebust wrote:
> >> The main use case for open by filehandle was (and still should be) the
> >> promise of being able to do the sort of tricks you normally associate
> >> with object storage on a standard filesystem.
> >> 
> >> Imagine that you are trying to build an application for indexing and
> >> searching the data on your storage. You basically want to trawl through
> >> the filesystem on a regular basis and build up a database of key words
> >> and other metadata to tell you what is in the files. For that kind of
> >> application, the namespace is a real PITA to deal with, because files
> >> get renamed, moved and deleted all the time; so if you can store
> >> something that is independent of the namespace and that will give you
> >> access to the file contents, then why wouldn't you do so? Normally,
> >> applications like that use the inode number, but you can't open a file
> >> by inode number, and you have the same problems with inode number reuse
> >> that a NFS server has.
> >> 
> >> That's the sort of thing I'd think we want to allow through open by
> >> filehandle, and I see no reason why NFS should be excluded from that
> >> type of application.
> > 
> > Thanks, that makes sense.
> > 
> > We've had open_by_handle support for most filesystems since 2011, is
> > there evidence of anyone doing this?
> 
> 
> I am pretty sure that nfs-ganesha is using this in one the backend
> implementations.

Yes, but I was curious about the kind of application Trond describes.

--b.

Re: open by handle support for NFS V2

[DENIEL Philippe]

On 07/01/17 11:34, Mkrtchyan, Tigran wrote:
>
> ----- Original Message -----
>> From: "J. Bruce Fields" <bfields@fieldses.org>
>> To: "Trond Myklebust" <trondmy@primarydata.com>
>> Cc: "Christoph Hellwig" <hch@lst.de>, "Jeff Layton" <jlayton@poochiereds.net>, "linux-nfs" <linux-nfs@vger.kernel.org>,
>> "schumaker anna" <schumaker.anna@gmail.com>
>> Sent: Friday, June 30, 2017 7:38:18 PM
>> Subject: Re: open by handle support for NFS V2
>> On Fri, Jun 30, 2017 at 05:00:59PM +0000, Trond Myklebust wrote:
>>> The main use case for open by filehandle was (and still should be) the
>>> promise of being able to do the sort of tricks you normally associate
>>> with object storage on a standard filesystem.
>>>
>>> Imagine that you are trying to build an application for indexing and
>>> searching the data on your storage. You basically want to trawl through
>>> the filesystem on a regular basis and build up a database of key words
>>> and other metadata to tell you what is in the files. For that kind of
>>> application, the namespace is a real PITA to deal with, because files
>>> get renamed, moved and deleted all the time; so if you can store
>>> something that is independent of the namespace and that will give you
>>> access to the file contents, then why wouldn't you do so? Normally,
>>> applications like that use the inode number, but you can't open a file
>>> by inode number, and you have the same problems with inode number reuse
>>> that a NFS server has.
>>>
>>> That's the sort of thing I'd think we want to allow through open by
>>> filehandle, and I see no reason why NFS should be excluded from that
>>> type of application.
>> Thanks, that makes sense.
>>
>> We've had open_by_handle support for most filesystems since 2011, is
>> there evidence of anyone doing this?
>
> I am pretty sure that nfs-ganesha is using this in one the backend
> implementations.
>
> Tigran.
Tigran is right: nfs-ganesha does something a bit similar to this in its 
"FSAL_VFS" module (the backed module based the usage of on 
open_by_handle_at() and name_to_handle_at() ).

     regards

         Philippe

>
>> --b.
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: open by handle support for NFS V2

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 2690 bytes --]

On Fri, Jun 30 2017, Trond Myklebust wrote:

> On Thu, 2017-06-29 at 11:46 -0400, J. Bruce Fields wrote:
>> On Thu, Jun 29, 2017 at 06:34:49AM -0700, Christoph Hellwig wrote:
>> > this resurrects parts of an old series to add open by handle
>> > support to
>> > NFS.  The prime intent here is to support the actual open by handle
>> > ioctls, although it will also allow very crude re-
>> > exporting.  Without
>> > the other patches from Jeff's series that re-exporting will suck
>> > badly
>> > though.
>> 
>> Why do we want this?
>> 
>> Any re-export support is going to have some major limitations.  (No
>> file
>> locking, and re-export of NFSv4 probably not possible?)
>> 
>> Last I heard the only motivation was extremely specific to Primary
>> Data's setup.  I'm happy to help them, but I think we need *some*
>> evidence this will be useful to upstream users.
>> 
>
> The main use case for open by filehandle was (and still should be) the
> promise of being able to do the sort of tricks you normally associate
> with object storage on a standard filesystem.
>
> Imagine that you are trying to build an application for indexing and
> searching the data on your storage. You basically want to trawl through
> the filesystem on a regular basis and build up a database of key words
> and other metadata to tell you what is in the files. For that kind of
> application, the namespace is a real PITA to deal with, because files
> get renamed, moved and deleted all the time; so if you can store
> something that is independent of the namespace and that will give you
> access to the file contents, then why wouldn't you do so? Normally,
> applications like that use the inode number, but you can't open a file
> by inode number, and you have the same problems with inode number reuse
> that a NFS server has.
>
> That's the sort of thing I'd think we want to allow through open by
> filehandle, and I see no reason why NFS should be excluded from that
> type of application.

Given that the goal, and presumably the testing, is focused on this
use-case, I wonder if we should take steps to disable the NFS-re-export
use case.
As the patch stands, I suspect that NFS re-export would appear to work,
but - as Bruce suggests - would likely hit some problems.  This might
not be a user-friendly thing to do.

Probably the ideal would be to keep re-export disabled by default, but
to allow it to be enabled using a module parameter.
I'm not sure the best way for NFS to tell nfsd that export shouldn't be
trusted.
Maybe add a "flags" field to struct export_operations, which can contain
a "No NFS export" flag ??

NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: open by handle support for NFS V2

[Trond Myklebust]

T24gRnJpLCAyMDE3LTA3LTA3IGF0IDEyOjQxICsxMDAwLCBOZWlsQnJvd24gd3JvdGU6DQo+IE9u
IEZyaSwgSnVuIDMwIDIwMTcsIFRyb25kIE15a2xlYnVzdCB3cm90ZToNCj4gDQo+ID4gT24gVGh1
LCAyMDE3LTA2LTI5IGF0IDExOjQ2IC0wNDAwLCBKLiBCcnVjZSBGaWVsZHMgd3JvdGU6DQo+ID4g
PiBPbiBUaHUsIEp1biAyOSwgMjAxNyBhdCAwNjozNDo0OUFNIC0wNzAwLCBDaHJpc3RvcGggSGVs
bHdpZw0KPiA+ID4gd3JvdGU6DQo+ID4gPiA+IHRoaXMgcmVzdXJyZWN0cyBwYXJ0cyBvZiBhbiBv
bGQgc2VyaWVzIHRvIGFkZCBvcGVuIGJ5IGhhbmRsZQ0KPiA+ID4gPiBzdXBwb3J0IHRvDQo+ID4g
PiA+IE5GUy7CoMKgVGhlIHByaW1lIGludGVudCBoZXJlIGlzIHRvIHN1cHBvcnQgdGhlIGFjdHVh
bCBvcGVuIGJ5DQo+ID4gPiA+IGhhbmRsZQ0KPiA+ID4gPiBpb2N0bHMsIGFsdGhvdWdoIGl0IHdp
bGwgYWxzbyBhbGxvdyB2ZXJ5IGNydWRlIHJlLQ0KPiA+ID4gPiBleHBvcnRpbmcuwqDCoFdpdGhv
dXQNCj4gPiA+ID4gdGhlIG90aGVyIHBhdGNoZXMgZnJvbSBKZWZmJ3Mgc2VyaWVzIHRoYXQgcmUt
ZXhwb3J0aW5nIHdpbGwNCj4gPiA+ID4gc3Vjaw0KPiA+ID4gPiBiYWRseQ0KPiA+ID4gPiB0aG91
Z2guDQo+ID4gPiANCj4gPiA+IFdoeSBkbyB3ZSB3YW50IHRoaXM/DQo+ID4gPiANCj4gPiA+IEFu
eSByZS1leHBvcnQgc3VwcG9ydCBpcyBnb2luZyB0byBoYXZlIHNvbWUgbWFqb3INCj4gPiA+IGxp
bWl0YXRpb25zLsKgwqAoTm8NCj4gPiA+IGZpbGUNCj4gPiA+IGxvY2tpbmcsIGFuZCByZS1leHBv
cnQgb2YgTkZTdjQgcHJvYmFibHkgbm90IHBvc3NpYmxlPykNCj4gPiA+IA0KPiA+ID4gTGFzdCBJ
IGhlYXJkIHRoZSBvbmx5IG1vdGl2YXRpb24gd2FzIGV4dHJlbWVseSBzcGVjaWZpYyB0bw0KPiA+
ID4gUHJpbWFyeQ0KPiA+ID4gRGF0YSdzIHNldHVwLsKgwqBJJ20gaGFwcHkgdG8gaGVscCB0aGVt
LCBidXQgSSB0aGluayB3ZSBuZWVkICpzb21lKg0KPiA+ID4gZXZpZGVuY2UgdGhpcyB3aWxsIGJl
IHVzZWZ1bCB0byB1cHN0cmVhbSB1c2Vycy4NCj4gPiA+IA0KPiA+IA0KPiA+IFRoZSBtYWluIHVz
ZSBjYXNlIGZvciBvcGVuIGJ5IGZpbGVoYW5kbGUgd2FzIChhbmQgc3RpbGwgc2hvdWxkIGJlKQ0K
PiA+IHRoZQ0KPiA+IHByb21pc2Ugb2YgYmVpbmcgYWJsZSB0byBkbyB0aGUgc29ydCBvZiB0cmlj
a3MgeW91IG5vcm1hbGx5DQo+ID4gYXNzb2NpYXRlDQo+ID4gd2l0aCBvYmplY3Qgc3RvcmFnZSBv
biBhIHN0YW5kYXJkIGZpbGVzeXN0ZW0uDQo+ID4gDQo+ID4gSW1hZ2luZSB0aGF0IHlvdSBhcmUg
dHJ5aW5nIHRvIGJ1aWxkIGFuIGFwcGxpY2F0aW9uIGZvciBpbmRleGluZw0KPiA+IGFuZA0KPiA+
IHNlYXJjaGluZyB0aGUgZGF0YSBvbiB5b3VyIHN0b3JhZ2UuIFlvdSBiYXNpY2FsbHkgd2FudCB0
byB0cmF3bA0KPiA+IHRocm91Z2gNCj4gPiB0aGUgZmlsZXN5c3RlbSBvbiBhIHJlZ3VsYXIgYmFz
aXMgYW5kIGJ1aWxkIHVwIGEgZGF0YWJhc2Ugb2Yga2V5DQo+ID4gd29yZHMNCj4gPiBhbmQgb3Ro
ZXIgbWV0YWRhdGEgdG8gdGVsbCB5b3Ugd2hhdCBpcyBpbiB0aGUgZmlsZXMuIEZvciB0aGF0IGtp
bmQNCj4gPiBvZg0KPiA+IGFwcGxpY2F0aW9uLCB0aGUgbmFtZXNwYWNlIGlzIGEgcmVhbCBQSVRB
IHRvIGRlYWwgd2l0aCwgYmVjYXVzZQ0KPiA+IGZpbGVzDQo+ID4gZ2V0IHJlbmFtZWQsIG1vdmVk
IGFuZCBkZWxldGVkIGFsbCB0aGUgdGltZTsgc28gaWYgeW91IGNhbiBzdG9yZQ0KPiA+IHNvbWV0
aGluZyB0aGF0IGlzIGluZGVwZW5kZW50IG9mIHRoZSBuYW1lc3BhY2UgYW5kIHRoYXQgd2lsbCBn
aXZlDQo+ID4geW91DQo+ID4gYWNjZXNzIHRvIHRoZSBmaWxlIGNvbnRlbnRzLCB0aGVuIHdoeSB3
b3VsZG4ndCB5b3UgZG8gc28/IE5vcm1hbGx5LA0KPiA+IGFwcGxpY2F0aW9ucyBsaWtlIHRoYXQg
dXNlIHRoZSBpbm9kZSBudW1iZXIsIGJ1dCB5b3UgY2FuJ3Qgb3BlbiBhDQo+ID4gZmlsZQ0KPiA+
IGJ5IGlub2RlIG51bWJlciwgYW5kIHlvdSBoYXZlIHRoZSBzYW1lIHByb2JsZW1zIHdpdGggaW5v
ZGUgbnVtYmVyDQo+ID4gcmV1c2UNCj4gPiB0aGF0IGEgTkZTIHNlcnZlciBoYXMuDQo+ID4gDQo+
ID4gVGhhdCdzIHRoZSBzb3J0IG9mIHRoaW5nIEknZCB0aGluayB3ZSB3YW50IHRvIGFsbG93IHRo
cm91Z2ggb3BlbiBieQ0KPiA+IGZpbGVoYW5kbGUsIGFuZCBJIHNlZSBubyByZWFzb24gd2h5IE5G
UyBzaG91bGQgYmUgZXhjbHVkZWQgZnJvbQ0KPiA+IHRoYXQNCj4gPiB0eXBlIG9mIGFwcGxpY2F0
aW9uLg0KPiANCj4gR2l2ZW4gdGhhdCB0aGUgZ29hbCwgYW5kIHByZXN1bWFibHkgdGhlIHRlc3Rp
bmcsIGlzIGZvY3VzZWQgb24gdGhpcw0KPiB1c2UtY2FzZSwgSSB3b25kZXIgaWYgd2Ugc2hvdWxk
IHRha2Ugc3RlcHMgdG8gZGlzYWJsZSB0aGUgTkZTLXJlLQ0KPiBleHBvcnQNCj4gdXNlIGNhc2Uu
DQo+IEFzIHRoZSBwYXRjaCBzdGFuZHMsIEkgc3VzcGVjdCB0aGF0IE5GUyByZS1leHBvcnQgd291
bGQgYXBwZWFyIHRvDQo+IHdvcmssDQo+IGJ1dCAtIGFzIEJydWNlIHN1Z2dlc3RzIC0gd291bGQg
bGlrZWx5IGhpdCBzb21lIHByb2JsZW1zLsKgwqBUaGlzIG1pZ2h0DQo+IG5vdCBiZSBhIHVzZXIt
ZnJpZW5kbHkgdGhpbmcgdG8gZG8uDQo+IA0KPiBQcm9iYWJseSB0aGUgaWRlYWwgd291bGQgYmUg
dG8ga2VlcCByZS1leHBvcnQgZGlzYWJsZWQgYnkgZGVmYXVsdCwNCj4gYnV0DQo+IHRvIGFsbG93
IGl0IHRvIGJlIGVuYWJsZWQgdXNpbmcgYSBtb2R1bGUgcGFyYW1ldGVyLg0KPiBJJ20gbm90IHN1
cmUgdGhlIGJlc3Qgd2F5IGZvciBORlMgdG8gdGVsbCBuZnNkIHRoYXQgZXhwb3J0IHNob3VsZG4n
dA0KPiBiZQ0KPiB0cnVzdGVkLg0KPiBNYXliZSBhZGQgYSAiZmxhZ3MiIGZpZWxkIHRvIHN0cnVj
dCBleHBvcnRfb3BlcmF0aW9ucywgd2hpY2ggY2FuDQo+IGNvbnRhaW4NCj4gYSAiTm8gTkZTIGV4
cG9ydCIgZmxhZyA/Pw0KPiANCg0KWW91IGNvdWxkLCBidXQgdGhlIHJlYXNvbiB3aHkgd2UgZGV2
ZWxvcGVkIHRoZSBjb2RlIGluIHRoZSBmaXJzdCBwbGFjZSwNCndhcyBiZWNhdXNlIHdlIGhhdmUg
YW4gaW50ZXJuYWwgdXNlIGNhc2Ugd2hpY2ggZG9lcyBpbnZvbHZlIHJlLWV4cG9ydA0Kb2YgTkZT
LCBzbyB3ZSdyZSBmYW1pbGlhciB3aXRoIHRoZSBsaW1pdGF0aW9ucy4NCg0KRllJLCB0aGUgbGlt
aXRhdGlvbnMgYXJlOg0KMSkgUmVjb3Zlcnkgb2YgbG9ja3MgaXMgbm90IHBvc3NpYmxlIHdoZW4g
dGhlIHJlLWV4cG9ydGluZyBzZXJ2ZXIgaXMNCnRoZSBvbmUgYmVpbmcgcmVib290ZWQuIEl0IHdv
cmtzIGp1c3QgZmluZSBmb3IgYWxsIG90aGVyIGNhc2VzLg0KMikgUmUtZXhwb3J0aW5nIGFueXRo
aW5nIHRvIE5GU3YyIGlzIG5vdCBwb3NzaWJsZS4NCjMpIFJlLWV4cG9ydCBvZiBmaWxlc3lzdGVt
cyB3aXRoIHZlcnkgbGFyZ2UgZmlsZW5hbmRsZXMgY291bGQgYmUNCnByb2JsZW1hdGljLiBUaGlz
IHdvdWxkIGFsc28gYWZmZWN0IG9wZW4tYnktZmlsZWhhbmRsZS4gSW4gcHJhY3RpY2UgaXQNCnR1
cm5zIG91dCB0byBiZSBhIG5vbi1pc3N1ZSBiZWNhdXNlIG5vYm9keSB1c2VzIGZpbGVoYW5kbGVz
ID4gNjQgYnl0ZXMuDQo0KSBTdGF0ZWxlc3MgTkZTdjMgcmVhZHMgYW5kIHdyaXRlcyBjYW4gYmUg
YSBwcm9ibGVtIHdpdGggTkZTdjQgd2hlbg0KdGhlIGFwcGxpY2F0aW9uIHVzZWVzIG9kZCBtb2Rl
Yml0IHNldHRpbmdzIHN1Y2ggYXMgMDAwLg0KDQpJT1c6IGluIHByYWN0aWNlIHRoaXMgaXMgbm8g
d29yc2UgdGhhbiBhbGwgdGhlIG90aGVyIHJlLWV4cG9ydGVycyBzdWNoDQphcyBhbHJlYWR5IGV4
aXN0IGZvciBnbHVzdGVyIC0+IE5GU3YzLCBjZXBoIC0+IE5GU3YzLCBORlMgLT4gU01CLC4uLg0K
YW5kIHdoaWNoIGV2ZXJ5b25lIHNlZW1zIGhhcHB5IHRvIHVzZS4NCg0KLS0gDQpUcm9uZCBNeWts
ZWJ1c3QNCkxpbnV4IE5GUyBjbGllbnQgbWFpbnRhaW5lciwgUHJpbWFyeURhdGENCnRyb25kLm15
a2xlYnVzdEBwcmltYXJ5ZGF0YS5jb20NCg==

Re: open by handle support for NFS V2

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 4551 bytes --]

On Fri, Jul 07 2017, Trond Myklebust wrote:

> On Fri, 2017-07-07 at 12:41 +1000, NeilBrown wrote:
>> On Fri, Jun 30 2017, Trond Myklebust wrote:
>> 
>> > On Thu, 2017-06-29 at 11:46 -0400, J. Bruce Fields wrote:
>> > > On Thu, Jun 29, 2017 at 06:34:49AM -0700, Christoph Hellwig
>> > > wrote:
>> > > > this resurrects parts of an old series to add open by handle
>> > > > support to
>> > > > NFS.  The prime intent here is to support the actual open by
>> > > > handle
>> > > > ioctls, although it will also allow very crude re-
>> > > > exporting.  Without
>> > > > the other patches from Jeff's series that re-exporting will
>> > > > suck
>> > > > badly
>> > > > though.
>> > > 
>> > > Why do we want this?
>> > > 
>> > > Any re-export support is going to have some major
>> > > limitations.  (No
>> > > file
>> > > locking, and re-export of NFSv4 probably not possible?)
>> > > 
>> > > Last I heard the only motivation was extremely specific to
>> > > Primary
>> > > Data's setup.  I'm happy to help them, but I think we need *some*
>> > > evidence this will be useful to upstream users.
>> > > 
>> > 
>> > The main use case for open by filehandle was (and still should be)
>> > the
>> > promise of being able to do the sort of tricks you normally
>> > associate
>> > with object storage on a standard filesystem.
>> > 
>> > Imagine that you are trying to build an application for indexing
>> > and
>> > searching the data on your storage. You basically want to trawl
>> > through
>> > the filesystem on a regular basis and build up a database of key
>> > words
>> > and other metadata to tell you what is in the files. For that kind
>> > of
>> > application, the namespace is a real PITA to deal with, because
>> > files
>> > get renamed, moved and deleted all the time; so if you can store
>> > something that is independent of the namespace and that will give
>> > you
>> > access to the file contents, then why wouldn't you do so? Normally,
>> > applications like that use the inode number, but you can't open a
>> > file
>> > by inode number, and you have the same problems with inode number
>> > reuse
>> > that a NFS server has.
>> > 
>> > That's the sort of thing I'd think we want to allow through open by
>> > filehandle, and I see no reason why NFS should be excluded from
>> > that
>> > type of application.
>> 
>> Given that the goal, and presumably the testing, is focused on this
>> use-case, I wonder if we should take steps to disable the NFS-re-
>> export
>> use case.
>> As the patch stands, I suspect that NFS re-export would appear to
>> work,
>> but - as Bruce suggests - would likely hit some problems.  This might
>> not be a user-friendly thing to do.
>> 
>> Probably the ideal would be to keep re-export disabled by default,
>> but
>> to allow it to be enabled using a module parameter.
>> I'm not sure the best way for NFS to tell nfsd that export shouldn't
>> be
>> trusted.
>> Maybe add a "flags" field to struct export_operations, which can
>> contain
>> a "No NFS export" flag ??
>> 
>
> You could, but the reason why we developed the code in the first place,
> was because we have an internal use case which does involve re-export
> of NFS, so we're familiar with the limitations.
>
> FYI, the limitations are:
> 1) Recovery of locks is not possible when the re-exporting server is
> the one being rebooted. It works just fine for all other cases.
> 2) Re-exporting anything to NFSv2 is not possible.
> 3) Re-export of filesystems with very large filenandles could be
> problematic. This would also affect open-by-filehandle. In practice it
> turns out to be a non-issue because nobody uses filehandles > 64 bytes.
> 4) Stateless NFSv3 reads and writes can be a problem with NFSv4 when
> the application usees odd modebit settings such as 000.
>
> IOW: in practice this is no worse than all the other re-exporters such
> as already exist for gluster -> NFSv3, ceph -> NFSv3, NFS -> SMB,...
> and which everyone seems happy to use.
>

Thanks.  That isn't as bad as I feared.  Maybe it would be useful to put
notes like in this in the nfs(5) man page.
For the NFSv2 export I suspect that in some cases you might be
able to successfully mount, but then not access anything.
The linux NFS server uses a very small file handles for an export-point.
It might be good to have nfs_encode_fh always fail if *max_len <= 32/4
just to ensure that NFSv2 doesn't even get off the ground.

Thanks,
NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: open by handle support for NFS V2

[Jeff Layton]

On Fri, 2017-07-07 at 14:27 +1000, NeilBrown wrote:
> On Fri, Jul 07 2017, Trond Myklebust wrote:
> 
> > On Fri, 2017-07-07 at 12:41 +1000, NeilBrown wrote:
> > > On Fri, Jun 30 2017, Trond Myklebust wrote:
> > > 
> > > > On Thu, 2017-06-29 at 11:46 -0400, J. Bruce Fields wrote:
> > > > > On Thu, Jun 29, 2017 at 06:34:49AM -0700, Christoph Hellwig
> > > > > wrote:
> > > > > > this resurrects parts of an old series to add open by handle
> > > > > > support to
> > > > > > NFS.  The prime intent here is to support the actual open by
> > > > > > handle
> > > > > > ioctls, although it will also allow very crude re-
> > > > > > exporting.  Without
> > > > > > the other patches from Jeff's series that re-exporting will
> > > > > > suck
> > > > > > badly
> > > > > > though.
> > > > > 
> > > > > Why do we want this?
> > > > > 
> > > > > Any re-export support is going to have some major
> > > > > limitations.  (No
> > > > > file
> > > > > locking, and re-export of NFSv4 probably not possible?)
> > > > > 
> > > > > Last I heard the only motivation was extremely specific to
> > > > > Primary
> > > > > Data's setup.  I'm happy to help them, but I think we need *some*
> > > > > evidence this will be useful to upstream users.
> > > > > 
> > > > 
> > > > The main use case for open by filehandle was (and still should be)
> > > > the
> > > > promise of being able to do the sort of tricks you normally
> > > > associate
> > > > with object storage on a standard filesystem.
> > > > 
> > > > Imagine that you are trying to build an application for indexing
> > > > and
> > > > searching the data on your storage. You basically want to trawl
> > > > through
> > > > the filesystem on a regular basis and build up a database of key
> > > > words
> > > > and other metadata to tell you what is in the files. For that kind
> > > > of
> > > > application, the namespace is a real PITA to deal with, because
> > > > files
> > > > get renamed, moved and deleted all the time; so if you can store
> > > > something that is independent of the namespace and that will give
> > > > you
> > > > access to the file contents, then why wouldn't you do so? Normally,
> > > > applications like that use the inode number, but you can't open a
> > > > file
> > > > by inode number, and you have the same problems with inode number
> > > > reuse
> > > > that a NFS server has.
> > > > 
> > > > That's the sort of thing I'd think we want to allow through open by
> > > > filehandle, and I see no reason why NFS should be excluded from
> > > > that
> > > > type of application.
> > > 
> > > Given that the goal, and presumably the testing, is focused on this
> > > use-case, I wonder if we should take steps to disable the NFS-re-
> > > export
> > > use case.
> > > As the patch stands, I suspect that NFS re-export would appear to
> > > work,
> > > but - as Bruce suggests - would likely hit some problems.  This might
> > > not be a user-friendly thing to do.
> > > 
> > > Probably the ideal would be to keep re-export disabled by default,
> > > but
> > > to allow it to be enabled using a module parameter.
> > > I'm not sure the best way for NFS to tell nfsd that export shouldn't
> > > be
> > > trusted.
> > > Maybe add a "flags" field to struct export_operations, which can
> > > contain
> > > a "No NFS export" flag ??
> > > 
> > 
> > You could, but the reason why we developed the code in the first place,
> > was because we have an internal use case which does involve re-export
> > of NFS, so we're familiar with the limitations.
> > 
> > FYI, the limitations are:
> > 1) Recovery of locks is not possible when the re-exporting server is
> > the one being rebooted. It works just fine for all other cases.
> > 2) Re-exporting anything to NFSv2 is not possible.
> > 3) Re-export of filesystems with very large filenandles could be
> > problematic. This would also affect open-by-filehandle. In practice it
> > turns out to be a non-issue because nobody uses filehandles > 64 bytes.
> > 4) Stateless NFSv3 reads and writes can be a problem with NFSv4 when
> > the application usees odd modebit settings such as 000.
> > 
> > IOW: in practice this is no worse than all the other re-exporters such
> > as already exist for gluster -> NFSv3, ceph -> NFSv3, NFS -> SMB,...
> > and which everyone seems happy to use.
> > 
> 
> Thanks.  That isn't as bad as I feared.  Maybe it would be useful to put
> notes like in this in the nfs(5) man page.
> For the NFSv2 export I suspect that in some cases you might be
> able to successfully mount, but then not access anything.
> The linux NFS server uses a very small file handles for an export-point.
> It might be good to have nfs_encode_fh always fail if *max_len <= 32/4
> just to ensure that NFSv2 doesn't even get off the ground.
> 

I just saw this on the LWN article entitled "4.13 Merge window, part 2":

   - NFS filesystems can now be re-exported over NFS.

I'm posting a comment there to try and clarify this, but it's a little
worrisome that this misconception is already getting out. I think we
need to do something to clear up this confusion, whether via
documentation or other means.
-- 
Jeff Layton <jlayton@redhat.com>

[PATCH 1/4] nfs: replace d_add with d_splice_alias in atomic_open

[Christoph Hellwig]

From: Peng Tao <tao.peng@primarydata.com>

It's a trival change but follows knfsd export document that asks
for d_splice_alias during lookup.

Signed-off-by: Peng Tao <tao.peng@primarydata.com>
---
 fs/nfs/dir.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c
index 32ccd7754f8a..0296c06dcdc5 100644
--- a/fs/nfs/dir.c
+++ b/fs/nfs/dir.c
@@ -1512,7 +1512,7 @@ int nfs_atomic_open(struct inode *dir, struct dentry *dentry,
 		d_drop(dentry);
 		switch (err) {
 		case -ENOENT:
-			d_add(dentry, NULL);
+			d_splice_alias(NULL, dentry);
 			nfs_set_verifier(dentry, nfs_save_change_attribute(dir));
 			break;
 		case -EISDIR:
-- 
2.11.0