From: Amir Goldstein <amir73il@gmail.com>
To: Christian Brauner <brauner@kernel.org>
Cc: Jeff Layton <jlayton@kernel.org>,
Chuck Lever <chuck.lever@oracle.com>,
linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org,
kernel test robot <lkp@intel.com>, Arnd Bergmann <arnd@arndb.de>
Subject: [PATCH] fs: fix build error with CONFIG_EXPORTFS=m or not defined
Date: Thu, 26 Oct 2023 23:45:40 +0300 [thread overview]
Message-ID: <20231026204540.143217-1-amir73il@gmail.com> (raw)
Many of the filesystems that call the generic exportfs helpers do not
select the EXPORTFS config.
Move generic_encode_ino32_fh() to libfs.c, same as generic_fh_to_*()
to avoid having to fix all those config dependencies.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202310262151.renqMvme-lkp@intel.com/
Fixes: dfaf653dc415 ("exportfs: make ->encode_fh() a mandatory method for NFS export")
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
---
Christian,
Soaking f_fsid in linux-next started to bring goodies.
Please feel free to apply the fix as is or squash it.
Thanks,
Amir.
fs/exportfs/expfs.c | 41 ----------------------------------------
fs/libfs.c | 41 ++++++++++++++++++++++++++++++++++++++++
include/linux/exportfs.h | 9 ++-------
3 files changed, 43 insertions(+), 48 deletions(-)
diff --git a/fs/exportfs/expfs.c b/fs/exportfs/expfs.c
index 7d9fdcc187b7..3ae0154c5680 100644
--- a/fs/exportfs/expfs.c
+++ b/fs/exportfs/expfs.c
@@ -342,47 +342,6 @@ static int get_name(const struct path *path, char *name, struct dentry *child)
return error;
}
-/**
- * generic_encode_ino32_fh - generic export_operations->encode_fh function
- * @inode: the object to encode
- * @fh: where to store the file handle fragment
- * @max_len: maximum length to store there (in 4 byte units)
- * @parent: parent directory inode, if wanted
- *
- * This generic encode_fh function assumes that the 32 inode number
- * is suitable for locating an inode, and that the generation number
- * can be used to check that it is still valid. It places them in the
- * filehandle fragment where export_decode_fh expects to find them.
- */
-int generic_encode_ino32_fh(struct inode *inode, __u32 *fh, int *max_len,
- struct inode *parent)
-{
- struct fid *fid = (void *)fh;
- int len = *max_len;
- int type = FILEID_INO32_GEN;
-
- if (parent && (len < 4)) {
- *max_len = 4;
- return FILEID_INVALID;
- } else if (len < 2) {
- *max_len = 2;
- return FILEID_INVALID;
- }
-
- len = 2;
- fid->i32.ino = inode->i_ino;
- fid->i32.gen = inode->i_generation;
- if (parent) {
- fid->i32.parent_ino = parent->i_ino;
- fid->i32.parent_gen = parent->i_generation;
- len = 4;
- type = FILEID_INO32_GEN_PARENT;
- }
- *max_len = len;
- return type;
-}
-EXPORT_SYMBOL_GPL(generic_encode_ino32_fh);
-
#define FILEID_INO64_GEN_LEN 3
/**
diff --git a/fs/libfs.c b/fs/libfs.c
index 8117b24b929d..38950cce135b 100644
--- a/fs/libfs.c
+++ b/fs/libfs.c
@@ -1310,6 +1310,47 @@ ssize_t simple_attr_write_signed(struct file *file, const char __user *buf,
}
EXPORT_SYMBOL_GPL(simple_attr_write_signed);
+/**
+ * generic_encode_ino32_fh - generic export_operations->encode_fh function
+ * @inode: the object to encode
+ * @fh: where to store the file handle fragment
+ * @max_len: maximum length to store there (in 4 byte units)
+ * @parent: parent directory inode, if wanted
+ *
+ * This generic encode_fh function assumes that the 32 inode number
+ * is suitable for locating an inode, and that the generation number
+ * can be used to check that it is still valid. It places them in the
+ * filehandle fragment where export_decode_fh expects to find them.
+ */
+int generic_encode_ino32_fh(struct inode *inode, __u32 *fh, int *max_len,
+ struct inode *parent)
+{
+ struct fid *fid = (void *)fh;
+ int len = *max_len;
+ int type = FILEID_INO32_GEN;
+
+ if (parent && (len < 4)) {
+ *max_len = 4;
+ return FILEID_INVALID;
+ } else if (len < 2) {
+ *max_len = 2;
+ return FILEID_INVALID;
+ }
+
+ len = 2;
+ fid->i32.ino = inode->i_ino;
+ fid->i32.gen = inode->i_generation;
+ if (parent) {
+ fid->i32.parent_ino = parent->i_ino;
+ fid->i32.parent_gen = parent->i_generation;
+ len = 4;
+ type = FILEID_INO32_GEN_PARENT;
+ }
+ *max_len = len;
+ return type;
+}
+EXPORT_SYMBOL_GPL(generic_encode_ino32_fh);
+
/**
* generic_fh_to_dentry - generic helper for the fh_to_dentry export operation
* @sb: filesystem to do the file handle conversion on
diff --git a/include/linux/exportfs.h b/include/linux/exportfs.h
index 21bae8bfeef1..e0e69dafaa43 100644
--- a/include/linux/exportfs.h
+++ b/include/linux/exportfs.h
@@ -294,17 +294,12 @@ extern struct dentry *exportfs_decode_fh(struct vfsmount *mnt, struct fid *fid,
/*
* Generic helpers for filesystems.
*/
-#ifdef CONFIG_EXPORTFS
int generic_encode_ino32_fh(struct inode *inode, __u32 *fh, int *max_len,
struct inode *parent);
-#else
-#define generic_encode_ino32_fh NULL
-#endif
-
-extern struct dentry *generic_fh_to_dentry(struct super_block *sb,
+struct dentry *generic_fh_to_dentry(struct super_block *sb,
struct fid *fid, int fh_len, int fh_type,
struct inode *(*get_inode) (struct super_block *sb, u64 ino, u32 gen));
-extern struct dentry *generic_fh_to_parent(struct super_block *sb,
+struct dentry *generic_fh_to_parent(struct super_block *sb,
struct fid *fid, int fh_len, int fh_type,
struct inode *(*get_inode) (struct super_block *sb, u64 ino, u32 gen));
--
2.34.1
next reply other threads:[~2023-10-26 20:45 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-26 20:45 Amir Goldstein [this message]
2023-10-27 6:59 ` [PATCH] fs: fix build error with CONFIG_EXPORTFS=m or not defined Arnd Bergmann
2023-10-27 8:02 ` Christian Brauner
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=20231026204540.143217-1-amir73il@gmail.com \
--to=amir73il@gmail.com \
--cc=arnd@arndb.de \
--cc=brauner@kernel.org \
--cc=chuck.lever@oracle.com \
--cc=jlayton@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=lkp@intel.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 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).