From: Huang Jianan <jnhuang95@gmail.com>
To: Qu Wenruo <wqu@suse.com>, u-boot@lists.denx.de
Cc: marek.behun@nic.cz, linux-btrfs@vger.kernel.org,
linux-erofs@lists.ozlabs.org, trini@konsulko.com,
joaomarcos.costa@bootlin.com, thomas.petazzoni@bootlin.com,
miquel.raynal@bootlin.com
Subject: Re: [PATCH RFC 2/8] fs: always get the file size in _fs_read()
Date: Tue, 28 Jun 2022 20:36:57 +0800 [thread overview]
Message-ID: <6f958407-0c3c-1cd6-ced2-08bc9c267d17@gmail.com> (raw)
In-Reply-To: <cd417bc9dc4b44c4ac8d98f146e47c98cf4aac5a.1656401086.git.wqu@suse.com>
Hi, wenruo,
在 2022/6/28 15:28, Qu Wenruo 写道:
> For _fs_read(), @len == 0 means we read the whole file.
> And we just pass @len == 0 to make each filesystem to handle it.
>
> In fact we have info->size() call to properly get the filesize.
>
> So we can not only call info->size() to grab the file_size for len == 0
> case, but also detect invalid @len (e.g. @len > file_size) in advance or
> truncate @len.
>
> This behavior also allows us to handle unaligned better in the incoming
> patches.
>
> Signed-off-by: Qu Wenruo <wqu@suse.com>
> ---
> fs/fs.c | 25 +++++++++++++++++++++----
> 1 file changed, 21 insertions(+), 4 deletions(-)
>
> diff --git a/fs/fs.c b/fs/fs.c
> index 6de1a3eb6d5d..d992cdd6d650 100644
> --- a/fs/fs.c
> +++ b/fs/fs.c
> @@ -579,6 +579,7 @@ static int _fs_read(const char *filename, ulong addr, loff_t offset, loff_t len,
> {
> struct fstype_info *info = fs_get_info(fs_type);
> void *buf;
> + loff_t file_size;
> int ret;
>
> #ifdef CONFIG_LMB
> @@ -589,10 +590,26 @@ static int _fs_read(const char *filename, ulong addr, loff_t offset, loff_t len,
> }
> #endif
>
> - /*
> - * We don't actually know how many bytes are being read, since len==0
> - * means read the whole file.
> - */
> + ret = info->size(filename, &file_size);
I get an error when running the erofs test cases. The return value isn't
as expected
when reading symlink file.
For symlink file, erofs_size will return the size of the symlink itself
here.
> + if (ret < 0) {
> + log_err("** Unable to get file size for %s, %d **\n",
> + filename, ret);
> + return ret;
> + }
> + if (offset >= file_size) {
> + log_err(
> + "** Invalid offset, offset (%llu) >= file size (%llu)\n",
> + offset, file_size);
> + return -EINVAL;
> +
> + }
> + if (len == 0 || offset + len > file_size) {
> + if (len > file_size)
> + log_info(
> + "** Truncate read length from %llu to %llu, as file size is %llu **\n",
> + len, file_size, file_size);
> + len = file_size - offset;
Then, we will get a wrong len in the case of len==0. So I think we need
to do something
extra with the symlink file?
Thanks,
Jianan
> + }
> buf = map_sysmem(addr, len);
> ret = info->read(filename, buf, offset, len, actread);
> unmap_sysmem(buf);
next prev parent reply other threads:[~2022-06-28 12:37 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-28 7:28 [PATCH 0/8] u-boot: fs: add generic unaligned read handling Qu Wenruo
2022-06-28 7:28 ` [PATCH RFC 1/8] fs: fat: unexport file_fat_read_at() Qu Wenruo
2022-06-30 10:06 ` Simon Glass
2022-06-28 7:28 ` [PATCH RFC 2/8] fs: always get the file size in _fs_read() Qu Wenruo
2022-06-28 12:36 ` Huang Jianan [this message]
2022-06-28 12:43 ` Qu Wenruo
2022-06-28 7:28 ` [PATCH RFC 3/8] fs: btrfs: move the unaligned read code to _fs_read() for btrfs Qu Wenruo
2022-06-28 7:28 ` [PATCH RFC 4/8] fs: ext4: rely on _fs_read() to pass block aligned range into ext4fs_read_file() Qu Wenruo
2022-06-28 7:28 ` [PATCH RFC 5/8] fs: fat: rely on higher layer to get block aligned read range Qu Wenruo
2022-06-28 7:28 ` [PATCH RFC 6/8] fs: sandboxfs: add sandbox_fs_get_blocksize() Qu Wenruo
2022-06-30 10:06 ` Simon Glass
2022-06-30 10:12 ` Qu Wenruo
2022-06-28 7:28 ` [PATCH RFC 7/8] fs: ubifs: rely on higher layer to do unaligned read Qu Wenruo
2022-06-28 7:28 ` [PATCH RFC 8/8] fs: erofs: add unaligned read range handling Qu Wenruo
2022-06-28 13:37 ` [PATCH 0/8] u-boot: fs: add generic unaligned read handling Sean Anderson
2022-06-28 14:17 ` Tom Rini
2022-06-29 1:40 ` Qu Wenruo
2022-06-29 12:53 ` Tom Rini
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=6f958407-0c3c-1cd6-ced2-08bc9c267d17@gmail.com \
--to=jnhuang95@gmail.com \
--cc=joaomarcos.costa@bootlin.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-erofs@lists.ozlabs.org \
--cc=marek.behun@nic.cz \
--cc=miquel.raynal@bootlin.com \
--cc=thomas.petazzoni@bootlin.com \
--cc=trini@konsulko.com \
--cc=u-boot@lists.denx.de \
--cc=wqu@suse.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