linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Huang Jianan <jnhuang95@gmail.com>, 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:43:42 +0800	[thread overview]
Message-ID: <c267985f-a1c5-5e86-f7b8-9c2f323d5547@gmx.com> (raw)
In-Reply-To: <6f958407-0c3c-1cd6-ced2-08bc9c267d17@gmail.com>



On 2022/6/28 20:36, Huang Jianan wrote:
> 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.

Indeed, this is a problem, in fact I also checked other fses, it looks
like we all just return the inode size for the softlink, thus size()
call can not be relied on for those cases.

While for the read() calls, every fs will do extra resolving for soft
links, thus it doesn't cause problems.


This can still be solved by not calling size() calls at all, and only do
the unaligned read handling for the leading block.

Thank you very much for pointing this bug out, would update the patchset
for that.

Thanks,
Qu
>> +    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);
>

  reply	other threads:[~2022-06-28 12:44 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
2022-06-28 12:43     ` Qu Wenruo [this message]
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=c267985f-a1c5-5e86-f7b8-9c2f323d5547@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=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;
as well as URLs for NNTP newsgroup(s).