From: Qu Wenruo <wqu@suse.com>
To: u-boot@lists.denx.de
Cc: marek.behun@nic.cz, linux-btrfs@vger.kernel.org,
jnhuang95@gmail.com, linux-erofs@lists.ozlabs.org,
trini@konsulko.com, joaomarcos.costa@bootlin.com,
thomas.petazzoni@bootlin.com, miquel.raynal@bootlin.com
Subject: [PATCH v3 0/8] U-boot: fs: add generic unaligned read offset handling
Date: Mon, 15 Aug 2022 19:45:11 +0800 [thread overview]
Message-ID: <cover.1660563403.git.wqu@suse.com> (raw)
[CHANGELOG]
v3:
- Fix an error that we always return 0 actread bytes for unsupported fses
For unsupported fses, we should also populate @total_read.
Or we will just read the data but still return 0 for actually bytes.
Now it pass all test_fs* cases.
v2
- Fix a linkage error where (U64 % U32) is called without proper helper
Fix it with U64 & (U32 - 1), as the U32 value (@blocksize) should
always be power of 2, thus (@blocksize - 1) is the mask we want to
calculate the offset inside the block.
Above change only affects the 4th patch, everything else is not
touched.
RFC->v1:
- More (manual) testing
Unfortunately, in the latest master (75967970850a), the fs-tests.sh
always seems to hang at preparing the fs image.
Thus still has to do manual testing, tested btrfs, ext4 and fat, with
aligned and unaligned read, also added soft link read, all looks fine here.
Extra testing is still appreciated.
- Two more btrfs specific bug fixes
All exposed during manual tests
- Remove the tailing unaligned block handling
In fact, all fses can easily handle such case, just a min() call is
enough.
- Remove the support for sandboxfs
Since it's using read() calls, really no need to do block alignment
check.
- Enhanced blocksize check
Ensure the returned blocksize is not only non-error, but also
non-zero.
Qu Wenruo (8):
fs: fat: unexport file_fat_read_at()
fs: btrfs: fix a bug which no data get read if the length is not 0
fs: btrfs: fix a crash if specified range is beyond file size
fs: btrfs: move the unaligned read code to _fs_read() for btrfs
fs: ext4: rely on _fs_read() to handle leading unaligned block read
fs: fat: rely on higher layer to get block aligned read range
fs: ubifs: rely on higher layer to do unaligned read
fs: erofs: add unaligned read range handling
fs/btrfs/btrfs.c | 33 ++++++++---
fs/btrfs/inode.c | 89 +++--------------------------
fs/erofs/internal.h | 1 +
fs/erofs/super.c | 6 ++
fs/ext4/ext4fs.c | 22 +++++++
fs/fat/fat.c | 17 +++++-
fs/fs.c | 130 +++++++++++++++++++++++++++++++++++++++---
fs/ubifs/ubifs.c | 13 +++--
include/btrfs.h | 1 +
include/erofs.h | 1 +
include/ext4fs.h | 1 +
include/fat.h | 3 +-
include/ubifs_uboot.h | 1 +
13 files changed, 212 insertions(+), 106 deletions(-)
--
2.37.1
next reply other threads:[~2022-08-15 11:47 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-15 11:45 Qu Wenruo [this message]
2022-08-15 11:45 ` [PATCH v3 1/8] fs: fat: unexport file_fat_read_at() Qu Wenruo
2022-08-15 11:45 ` [PATCH v3 2/8] fs: btrfs: fix a bug which no data get read if the length is not 0 Qu Wenruo
2022-08-15 11:45 ` [PATCH v3 3/8] fs: btrfs: fix a crash if specified range is beyond file size Qu Wenruo
2022-08-15 11:45 ` [PATCH v3 4/8] fs: btrfs: move the unaligned read code to _fs_read() for btrfs Qu Wenruo
2022-08-15 11:45 ` [PATCH v3 5/8] fs: ext4: rely on _fs_read() to handle leading unaligned block read Qu Wenruo
2022-08-15 11:45 ` [PATCH v3 6/8] fs: fat: rely on higher layer to get block aligned read range Qu Wenruo
2022-08-15 11:45 ` [PATCH v3 7/8] fs: ubifs: rely on higher layer to do unaligned read Qu Wenruo
2022-08-15 11:45 ` [PATCH v3 8/8] fs: erofs: add unaligned read range handling Qu Wenruo
2022-08-26 14:29 ` [PATCH v3 0/8] U-boot: fs: add generic unaligned read offset handling 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=cover.1660563403.git.wqu@suse.com \
--to=wqu@suse.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 \
/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