All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gao Xiang <xiang@kernel.org>
To: Hongbo Li <lihongbo22@huawei.com>
Cc: xiang@kernel.org, chao@kernel.org, zbestahu@gmail.com,
	jefflexu@linux.alibaba.com, dhavale@google.com,
	linux-erofs@lists.ozlabs.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] erofs: encode file handle with the internal helpers
Date: Tue, 29 Apr 2025 11:31:05 +0800	[thread overview]
Message-ID: <aBBH+Wrwa1xXFGmo@debian> (raw)
In-Reply-To: <20250429011139.686847-1-lihongbo22@huawei.com>

Hi Hongbo,

I think the subject can be updated as:
`erofs-utils: fix file handle encoding for 64-bit NIDs`

On Tue, Apr 29, 2025 at 01:11:39AM +0000, Hongbo Li wrote:
> In erofs, the inode number has the location information of
> files. The default encode_fh uses the ino32, this will lack
> of some information when the file is too big. So we need
> the internal helpers to encode filehandle.
> 
> Since i_generation in EROFS is not used, here we only encode
> the nid into file handle when it is exported. So it is easy
> to parse the dentry from file handle.

If `FILEID_INO64_GEN_PARENT` is used, I don't think
the generation number should be emitted, as documented as:

`
/*
 * 64 bit inode number, 32 bit generation number.
 */
FILEID_INO64_GEN = 0x81,

/*
 * 64 bit inode number, 32 bit generation number,
 * 64 bit parent inode number, 32 bit parent generation.
 */
FILEID_INO64_GEN_PARENT = 0x82,
` 

Even the generation number is 0 but we might use
i_generation for some remote update use cases
in the future.

> 
> It is easy to reproduce test:
>   1. prepare an erofs image with nid bigger than UINT_MAX
>   2. mount -t erofs foo.img /mnt/erofs
>   3. set exportfs with configuration: /mnt/erofs *(rw,sync,
>      no_root_squash)
>   4. mount -t nfs $IP:/mnt/erofs /mnt/nfs
>   5. md5sum /mnt/nfs/foo # foo is the file which nid bigger
>      than UINT_MAX.
> For overlayfs case, the under filesystem's file handle is
> encoded in ovl_fb.fid, it is same as NFS's case.

Can we have a way to add a testcase for the overlayfs case:
since it's somewhat complex to write a testcase with nfs
above.

> 
> Fixes: 3e917cc305c6 ("erofs: make filesystem exportable")
> Signed-off-by: Hongbo Li <lihongbo22@huawei.com>
> ---
>  fs/erofs/super.c | 51 ++++++++++++++++++++++++++++++++++++++++--------
>  1 file changed, 43 insertions(+), 8 deletions(-)
> 
> diff --git a/fs/erofs/super.c b/fs/erofs/super.c
> index cadec6b1b554..8f787c47e04d 100644
> --- a/fs/erofs/super.c
> +++ b/fs/erofs/super.c
> @@ -511,24 +511,59 @@ static int erofs_fc_parse_param(struct fs_context *fc,
>  	return 0;
>  }
>  
> -static struct inode *erofs_nfs_get_inode(struct super_block *sb,
> -					 u64 ino, u32 generation)
> +static int erofs_encode_fh(struct inode *inode, u32 *fh, int *max_len,
> +			   struct inode *parent)
>  {
> -	return erofs_iget(sb, ino);
> +	int len = parent ? 4 : 2;
> +	erofs_nid_t nid;
> +
> +	if (*max_len < len) {
> +		*max_len = len;
> +		return FILEID_INVALID;
> +	}
> +
> +	nid = EROFS_I(inode)->nid;
> +	fh[0] = (u32)(nid >> 32);
> +	fh[1] = (u32)(nid & 0xffffffff);
> +
> +	if (parent) {
> +		nid = EROFS_I(parent)->nid;
> +
> +		fh[2] = (u32)(nid >> 32);
> +		fh[3] = (u32)(nid & 0xffffffff);
> +	}
> +
> +	*max_len = len;
> +	return parent ? FILEID_INO64_GEN_PARENT : FILEID_INO64_GEN;
>  }
>  
>  static struct dentry *erofs_fh_to_dentry(struct super_block *sb,
>  		struct fid *fid, int fh_len, int fh_type)
>  {
> -	return generic_fh_to_dentry(sb, fid, fh_len, fh_type,
> -				    erofs_nfs_get_inode);
> +	erofs_nid_t nid;
> +
> +	if ((fh_type != FILEID_INO64_GEN &&
> +	     fh_type != FILEID_INO64_GEN_PARENT) || fh_len < 2)
> +		return NULL;
> +
> +	nid = (u64) fid->raw[0] << 32;
> +	nid |= (u64) fid->raw[1];
> +

Redundant new line.

> +	return d_obtain_alias(erofs_iget(sb, nid));
>  }
>  
>  static struct dentry *erofs_fh_to_parent(struct super_block *sb,
>  		struct fid *fid, int fh_len, int fh_type)
>  {
> -	return generic_fh_to_parent(sb, fid, fh_len, fh_type,
> -				    erofs_nfs_get_inode);
> +	erofs_nid_t nid;
> +
> +	if (fh_type != FILEID_INO64_GEN_PARENT || fh_len < 4)
> +		return NULL;
> +
> +	nid = (u64) fid->raw[2] << 32;
> +	nid |= (u64) fid->raw[3];
> +

Same here.

Thanks,
Gao Xiang


  reply	other threads:[~2025-04-29  3:31 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-29  1:11 [PATCH] erofs: encode file handle with the internal helpers Hongbo Li
2025-04-29  3:31 ` Gao Xiang [this message]
2025-04-29  7:40   ` Hongbo Li

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=aBBH+Wrwa1xXFGmo@debian \
    --to=xiang@kernel.org \
    --cc=chao@kernel.org \
    --cc=dhavale@google.com \
    --cc=jefflexu@linux.alibaba.com \
    --cc=lihongbo22@huawei.com \
    --cc=linux-erofs@lists.ozlabs.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=zbestahu@gmail.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.