Re: [PATCH] fs/erofs: fix an overflow issue of unmapped extents
On 2024/6/5 22:05, Jianan Huang wrote:
Here the size should be `length - skip`, otherwise it could cause
the destination buffer overflow.
Reported-by: jianqiang wang
Fixes: 65cb73057b65 ("fs/erofs: add lz4 decompression support")
Signed-off-by: Jianan Huang
Reviewed-by: Gao Xiang
Thanks,
Gao Xiang
Re: Several potential vulnerabilities in the filesystem
On 2024/6/5 19:26, jianqiang wang wrote:
Hi Xiang,
I just checked the second crash, the patch can solve this issue. Did
you also look into the other two issues?
I'm only responsible for the EROFS project.
Thanks,
Gao Xiang
Best
Jianqiang
Gao Xiang 于2024年6月5日周三 13:18写道：
Hi Jianqiang,
On 2024/6/5 19:00, jianqiang wang wrote:
Hi,
I do have the crafted image.
payload_00500, payload_00763, payload_00846 can be used to reproduce
1,2,3 vulnerabilities respectively.
Each image is a hard drive file and the vulnerabilities can be
triggered by performing the following operations:
struct udevice *dev;
uclass_first_device_err(UCLASS_IDE, ); //detect the block device
fs_set_blk_dev("ide","0:1", 0);
fs_ls("/"); //mount the first partition and list the root directory
files
fs_set_blk_dev("ide","0:1", 0);
char buf[10];
buf[0] = 0;
buf[1] = 0;
buf[2] = 0;
buf[3] = 0;
loff_t actread = 0;
fs_read("/a.txt", (ulong)buf, 0, 5, );
printf("fd actread %lld %x %x %x\n",actread,buf[0],buf[1],buf[2]);
read the /a.txt file
fs_set_blk_dev("ide","0:1", 0);
fs_read("/a.txt.ln", (ulong)buf, 0, 5, );
printf("fd actread %lld %x %x %x\n",actread,buf[0],buf[1],buf[2]);
read the /a.txt.ln symbol file
fs_set_blk_dev("ide","0:1", 0);
fs_unlink("/a.txt.ln"); //unlink it
The second and third may not trigger a crash however, can be observed
by inserting logging before the memset/memcpy function.
Sorry, I just found that this issue was already fixed in erofs-utils:
https://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs-utils.git/commit/?id=884866ca07817e97c59605a2fa858a0b732d3f3c
Would you mind checking if the patch above fixes the issue?
Hi Jianan,
Would you mind backporting this patch for u-boot?
Thanks,
Gao Xiang
Best regards
Gao Xiang 于2024年6月5日周三 05:10写道：
On 2024/6/5 06:53, jianqiang wang wrote:
Hi Das U-Boot developers,
...
2. in file fs/erofs/data.c, function z_erofs_read_one_data, the node
data is read from the storage, however, without a proper check, the
data can be corrupted. For example, the inode data is used in function
z_erofs_read_data, map.m_llen will be calculated to a very large
value, which means the length variable will be very large. It will
cause a large memory clear with memset(buffer + end - offset, 0,
length);
Would you mind giving a reproducer or a crafted image to trigger
this? Or it's your pure observation.
Thanks,
Gao XIang
Re: Several potential vulnerabilities in the filesystem
Hi Jianqiang,
On 2024/6/5 19:00, jianqiang wang wrote:
Hi,
I do have the crafted image.
payload_00500, payload_00763, payload_00846 can be used to reproduce
1,2,3 vulnerabilities respectively.
Each image is a hard drive file and the vulnerabilities can be
triggered by performing the following operations:
struct udevice *dev;
uclass_first_device_err(UCLASS_IDE, ); //detect the block device
fs_set_blk_dev("ide","0:1", 0);
fs_ls("/"); //mount the first partition and list the root directory files
fs_set_blk_dev("ide","0:1", 0);
char buf[10];
buf[0] = 0;
buf[1] = 0;
buf[2] = 0;
buf[3] = 0;
loff_t actread = 0;
fs_read("/a.txt", (ulong)buf, 0, 5, );
printf("fd actread %lld %x %x %x\n",actread,buf[0],buf[1],buf[2]);
read the /a.txt file
fs_set_blk_dev("ide","0:1", 0);
fs_read("/a.txt.ln", (ulong)buf, 0, 5, );
printf("fd actread %lld %x %x %x\n",actread,buf[0],buf[1],buf[2]);
read the /a.txt.ln symbol file
fs_set_blk_dev("ide","0:1", 0);
fs_unlink("/a.txt.ln"); //unlink it
The second and third may not trigger a crash however, can be observed
by inserting logging before the memset/memcpy function.
Sorry, I just found that this issue was already fixed in erofs-utils:
https://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs-utils.git/commit/?id=884866ca07817e97c59605a2fa858a0b732d3f3c
Would you mind checking if the patch above fixes the issue?
Hi Jianan,
Would you mind backporting this patch for u-boot?
Thanks,
Gao Xiang
Best regards
Gao Xiang 于2024年6月5日周三 05:10写道：
On 2024/6/5 06:53, jianqiang wang wrote:
Hi Das U-Boot developers,
...
2. in file fs/erofs/data.c, function z_erofs_read_one_data, the node
data is read from the storage, however, without a proper check, the
data can be corrupted. For example, the inode data is used in function
z_erofs_read_data, map.m_llen will be calculated to a very large
value, which means the length variable will be very large. It will
cause a large memory clear with memset(buffer + end - offset, 0,
length);
Would you mind giving a reproducer or a crafted image to trigger
this? Or it's your pure observation.
Thanks,
Gao XIang
Re: Several potential vulnerabilities in the filesystem
On 2024/6/5 06:53, jianqiang wang wrote: Hi Das U-Boot developers, ... 2. in file fs/erofs/data.c, function z_erofs_read_one_data, the node data is read from the storage, however, without a proper check, the data can be corrupted. For example, the inode data is used in function z_erofs_read_data, map.m_llen will be calculated to a very large value, which means the length variable will be very large. It will cause a large memory clear with memset(buffer + end - offset, 0, length); Would you mind giving a reproducer or a crafted image to trigger this? Or it's your pure observation. Thanks, Gao XIang
Re: [PATCH v4 2/5] lib/lz4: update LZ4 decompressor module
On 2024/5/28 21:28, Jonathan Liu wrote:
Hi Jianan,
Here are the LZ4 decompression times I got running "time unlz4 ..." on
Rock 4 SE with RK3399 CPU.
v2024.04: 1.329 seconds
v2024.04 with 26c7fdadcb7 ("lib/lz4: update LZ4 decompressor module")
reverted: 0.665 seconds
v2024.04 with your patch: 1.216 seconds
I managed to get better performance by optimizing it myself.
v2024.04 with my patch: 0.785 seconds
With my patch, it makes no difference if I use __builtin_memcpy or
memcpy in lz4.c and lz4_wrapper.c so I just left it using memcpy.
It is still slower than reverting the LZ4 update though.
I'm not sure what's the old version come from, but from the copyright
itself it seems some earlier 2015 version. Note that there is no
absolute outperform between old version and new version, old version
may be lack of some necessary boundary check or lead to some msan
warning or something, like a new commit of year 2016:
https://github.com/lz4/lz4/commit/f094f531441140f10fd461ba769f49d10f5cd581
/* costs ~1%; silence an msan warning when offset == 0 */
/*
* note : when partialDecoding, there is no guarantee that
* at least 4 bytes remain available in output buffer
*/
if (!partialDecoding) {
assert(oend > op);
assert(oend - op >= 4);
LZ4_write32(op, (U32)offset);
}
For the example above, you could completely remove the line above if
you don't care about such warning, as it claims ~1% performance loss.
Also since no u-boot user uses in-place decompression and if
you memmove() doesn't behave well, you could update the
following line
/*
* supports overlapping memory regions; only matters
* for in-place decompression scenarios
*/
memmove(op, ip, length);
into memcpy() instead.
The new lz4 codebase relies on memcpy() / memmove() code optimization
more than old version, if memcpy() assembly doesn't generate well on
your platform, it might have some issue.
Thanks,
Gao Xiang
My patch:
--- a/lib/lz4.c
+++ b/lib/lz4.c
@@ -41,6 +41,16 @@ static FORCE_INLINE u16 LZ4_readLE16(const void *src)
return get_unaligned_le16(src);
}
+static FORCE_INLINE void LZ4_copy2(void *dst, const void *src)
+{
+ put_unaligned(get_unaligned((const u16 *)src), (u16 *)dst);
+}
+
+static FORCE_INLINE void LZ4_copy4(void *dst, const void *src)
+{
+ put_unaligned(get_unaligned((const u32 *)src), (u32 *)dst);
+}
+
static FORCE_INLINE void LZ4_copy8(void *dst, const void *src)
{
put_unaligned(get_unaligned((const u64 *)src), (u64 *)dst);
@@ -215,7 +225,10 @@ static FORCE_INLINE int LZ4_decompress_generic(
&& likely((endOnInput ? ip < shortiend : 1) &
(op <= shortoend))) {
/* Copy the literals */
- memcpy(op, ip, endOnInput ? 16 : 8);
+ LZ4_copy8(op, ip);
+ if (endOnInput)
+ LZ4_copy8(op + 8, ip + 8);
+
op += length; ip += length;
/*
@@ -234,9 +247,9 @@ static FORCE_INLINE int LZ4_decompress_generic(
(offset >= 8) &&
(dict == withPrefix64k || match >= lowPrefix)) {
/* Copy the match. */
- memcpy(op + 0, match + 0, 8);
- memcpy(op + 8, match + 8, 8);
- memcpy(op + 16, match + 16, 2);
+ LZ4_copy8(op, match);
+ LZ4_copy8(op + 8, match + 8);
+ LZ4_copy2(op + 16, match + 16);
op += length + MINMATCH;
/* Both stages worked, load the next token. */
continue;
@@ -466,7 +479,7 @@ _copy_match:
op[2] = match[2];
op[3] = match[3];
match += inc32table[offset];
- memcpy(op + 4, match, 4);
+ LZ4_copy4(op + 4, match);
match -= dec64table[offset];
} else {
LZ4_copy8(op, match);
Let me know if you have any further suggestions.
Thanks.
Regards,
Jonathan
On Sun, 26 May 2024 at 22:18, Jianan Huang wrote:
Hi Jonathan,
Could you please try the following patch ? It replaces all memcpy() calls in
lz4 with __builtin_memcpy().
diff --git a/lib/lz4.c b/lib/lz4.c
index d365dc727c..2afe31c1c3 100644
--- a/lib/lz4.c
+++ b/lib/lz4.c
@@ -34,6 +34,8 @@
#include
#include
+#define LZ4_memcpy(dst, src, size) __builtin_memcpy(dst, src, size)
+
#define FORCE_INLINE inline
Re: [PATCH v4 2/5] lib/lz4: update LZ4 decompressor module
Hi, On 2024/5/24 22:26, Jonathan Liu wrote: Hi Jianan, On Sat, 26 Feb 2022 at 18:05, Huang Jianan wrote: Update the LZ4 compression module based on LZ4 v1.8.3 in order to use the newest LZ4_decompress_safe_partial() which can now decode exactly the nb of bytes requested. Signed-off-by: Huang Jianan I noticed after this commit LZ4 decompression is slower. ulz4fn function call takes 1.209670 seconds with this commit. After reverting this commit, the ulz4fn function call takes 0.587032 seconds. I am decompressing a LZ4 compressed kernel (compressed with lz4 v1.9.4 using -9 option for maximum compression) on RK3399. Any ideas why it is slower with this commit and how the performance regression can be fixed? Just the quick glance, I think the issue may be due to memcpy/memmove since it seems the main difference between these two codebases (I'm not sure which LZ4 version the old codebase was based on) and the new version mainly relies on memcpy/memmove instead of its own versions. Would you mind to check the assembly how memcpy/memset is generated on your platform? Thanks, Gao Xiang Thanks. Regards, Jonathan
Re: [PATCH] fs/erofs: add DEFLATE algorithm support
Hi Jianan, On Sun, Apr 14, 2024 at 11:04:14PM +0800, Jianan Huang wrote: > This patch adds DEFLATE compression algorithm support. It's a good choice > to trade off between compression ratios and performance compared to LZ4. > Alternatively, DEFLATE could be used for some specific files since EROFS > supports multiple compression algorithms in one image. > > Signed-off-by: Jianan Huang Reviewed-by: Gao Xiang Thanks, Gao Xiang
Re: [PATCH 1/1] fs/erofs: avoid noisy messages
Hi Heinrich, On 2023/8/17 15:01, Heinrich Schuchardt wrote: The erofs file system creates noisy messages when it is not used: => host bind 0 disk.img => part list host 0 cannot find valid erofs superblock cannot find valid erofs superblock Partition Map for HOST device 0 -- Partition Type: EFI If there is not erofs file system, this only deserves a debug message. Signed-off-by: Heinrich Schuchardt There was already a patch to address that: https://lore.kernel.org/u-boot/20230813142708.361456-13-...@chromium.org/ Anyway, I'm fine with either patch. For this patch, Reviewed-by: Gao Xiang Thanks, Gao Xiang
Re: [PATCH 12/24] fs/erofs: Quieten test for filesystem presence
On 2023/8/13 22:26, Simon Glass wrote: At present listing a partition produces lots of errors about this filesystem: => part list mmc 4 cannot find valid erofs superblock cannot find valid erofs superblock cannot read erofs superblock: -5 [9 more similar lines] Use debugging rather than errors when unable to find a signature, as is done with other filesystems. Signed-off-by: Simon Glass Reviewed-by: Gao Xiang Thanks, Gao Xiang
Re: [PATCH] fs/erofs: Remove an unnecessary assertion
On 2023/7/26 12:56, Yifan Zhao wrote:
In [1] Sam points out an assertion does not hold true for 32-bit
platforms, which only impacts Large File Support (LFS) API usage
in erofs-utils according to Xiang [2]. We don't think these APIs
are used in u-boot and this restriction could be safely removed.
[1] https://lists.denx.de/pipermail/u-boot/2023-July/524679.html
[2] https://lists.denx.de/pipermail/u-boot/2023-July/524727.html
Fixes: 3a21e92fc255 ("fs/erofs: Introduce new features including ztailpacking,
fragments and dedupe")
Signed-off-by: Yifan Zhao
Acked-by: Gao Xiang
Thanks,
Gao Xiang
Re: [PATCH] fs/erofs: Introduce new features including ztailpacking, fragments and dedupe
Hi Sam, On 2023/7/26 05:40, Sam Edwards wrote: Hi folks, On 7/7/23 09:52, Yifan Zhao wrote: diff --git a/fs/erofs/internal.h b/fs/erofs/internal.h index 4af7c91560..433a3c6c1e 100644 --- a/fs/erofs/internal.h +++ b/fs/erofs/internal.h +/* make sure that any user of the erofs headers has at least 64bit off_t type */ +extern int erofs_assert_largefile[sizeof(off_t) - 8]; This assertion does not hold true on 32-bit platforms, and as a result this patch prevents building U-Boot on those systems with EROFS support enabled. Did you perhaps mean to use `erofs_off_t` (which is always 64-bit) somewhere that you're using `off_t` instead? I have had to revert this patch on my target, pending a solution for 32-bit users. Thanks for your report. I think this line could just be removed since it only impacts LFS APIs ["erofs-utils which uses _FILE_OFFSET_BITS=64"] directly: https://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs-utils.git/commit/?id=8b88487e20a8fb79942793d2bd8fe9bd2b15ba62 https://lore.kernel.org/all/20221215085842.130804-1-raj.k...@gmail.com/ But EROFS userspace internal implementation doesn't use off_t directly (instead it uses erofs_off_t as you said) nor u-boot interfaces (I think). Yifan, Could you submit a patch to remove this line? Thanks, Gao Xiang Thanks, Sam
Re: [PATCH] fs/erofs: Introduce new features including ztailpacking, fragments and dedupe
On 2023/7/17 23:12, Tom Rini wrote: On Mon, Jul 17, 2023 at 01:27:39PM +0800, Gao Xiang wrote: Hi Tom, On 2023/7/7 23:52, Yifan Zhao wrote: This patch updates erofs driver code to catch up with the latest code of erofs_utils (commit e4939f9eaa177e05d697ace85d8dc283e25dc2ed). LZMA will be supported in the separate patch later. Signed-off-by: Yifan Zhao --- CI result here: https://github.com/u-boot/u-boot/pull/344 Could you consider this patch for this merge window? LZMA support needs further work, we will address it separately. Yes, but I'm waiting a little bit longer for anyone else to provide feedback, thanks. Thank you! glad to hear that. :-) Thanks, Gao Xiang
Re: [PATCH] fs/erofs: Introduce new features including ztailpacking, fragments and dedupe
Hi Tom, On 2023/7/7 23:52, Yifan Zhao wrote: This patch updates erofs driver code to catch up with the latest code of erofs_utils (commit e4939f9eaa177e05d697ace85d8dc283e25dc2ed). LZMA will be supported in the separate patch later. Signed-off-by: Yifan Zhao --- CI result here: https://github.com/u-boot/u-boot/pull/344 Could you consider this patch for this merge window? LZMA support needs further work, we will address it separately. Thanks, Gao Xiang
Re: [PATCH 1/1] fs/erofs: silence erofs_probe()
On Sun, Jul 31, 2022 at 10:53:52PM +0200, Heinrich Schuchardt wrote:
>
>
> On 7/31/22 20:41, Simon Glass wrote:
> > On Sun, 31 Jul 2022 at 03:10, Heinrich Schuchardt
> > wrote:
> > >
> > > fs_set_blk_dev() probes all file-systems until it finds one that matches
> > > the volume. We do not expect any console output for non-matching
> > > file-systems.
> > >
> > > Convert error messages in erofs_read_superblock() to debug output.
> > >
> > > Fixes: 830613f8f5bb ("fs/erofs: add erofs filesystem support")
> > > Signed-off-by: Heinrich Schuchardt
> > > ---
> > > fs/erofs/super.c | 6 +++---
> > > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > Reviewed-by: Simon Glass
> >
> > >
> > > diff --git a/fs/erofs/super.c b/fs/erofs/super.c
> > > index 4cca322b9e..095754dc28 100644
> > > --- a/fs/erofs/super.c
> > > +++ b/fs/erofs/super.c
> > > @@ -65,14 +65,14 @@ int erofs_read_superblock(void)
> > >
> > > ret = erofs_blk_read(data, 0, 1);
> > > if (ret < 0) {
> > > - erofs_err("cannot read erofs superblock: %d", ret);
> > > + erofs_dbg("cannot read erofs superblock: %d", ret);
> > > return -EIO;
> > > }
> > > dsb = (struct erofs_super_block *)(data + EROFS_SUPER_OFFSET);
> > >
> > > ret = -EINVAL;
> > > if (le32_to_cpu(dsb->magic) != EROFS_SUPER_MAGIC_V1) {
> > > - erofs_err("cannot find valid erofs superblock");
> > > + erofs_dbg("cannot find valid erofs superblock");
> > > return ret;
> > > }
> >
> > > @@ -81,7 +81,7 @@ int erofs_read_superblock(void)
> > > blkszbits = dsb->blkszbits;
> > > /* 9(512 bytes) + LOG_SECTORS_PER_BLOCK == LOG_BLOCK_SIZE */
> > > if (blkszbits != LOG_BLOCK_SIZE) {
> > > - erofs_err("blksize %u isn't supported on this platform",
> > > + erofs_dbg("blksize %u isn't supported on this platform",
> > >1 << blkszbits);
> >
> > Does this message appear in normal scanning, or is it a genuine error?
>
> The erofs driver on Linux only supports LOG_BLOCK_SIZE == 12. So if we see
> this message we don't have a valid erofs file system.
>
> @linux-erofs:
>
> The Linux driver requires EROFS_BLKSIZ == PAGE_SIZE == 4096.
> The page size on arm64 can be 4 KiB, 16 KiB, or 64 KiB.
> The page size on amd64 can be 4 KiB, 2 MiB or 4 MiB.
> Requiring EROFS_BLKSIZ == PAGE_SIZE is obviously a restriction that should
> be lifted.
Yeah, EROFS doesn't support EROFS_BLKSIZ != PAGE_SIZE explicitly for now,
please help error out this message. Thanks!
Thanks,
Gao Xiang
>
> Best regards
>
> Heinrich
Re: [PATCH v3 0/5] fs/erofs: new filesystem
On Thu, Feb 10, 2022 at 08:34:55AM -0500, Tom Rini wrote: > On Thu, Feb 10, 2022 at 08:43:20PM +0800, Gao Xiang wrote: > > > Hi Tom, > > > > Would you mind taking some time having a look at this version > > if it meets what's needed, so we could have a chance to be > > merged in the next u-boot version? > > > > It's almost in sync with the latest erofs-utils soruce code, > > so it can be upgraded easily in the future together with the > > later erofs-utils versions. > > Things seem fine, we just need to also update the Dockerfile with tools > so that the tests are run. Many thanks! Hopefully Jianan could fill the gap later. Thanks, Gao Xiang > > -- > Tom
Re: [PATCH v3 0/5] fs/erofs: new filesystem
Hi Tom, Would you mind taking some time having a look at this version if it meets what's needed, so we could have a chance to be merged in the next u-boot version? It's almost in sync with the latest erofs-utils soruce code, so it can be upgraded easily in the future together with the later erofs-utils versions. Thanks, Gao Xiang On Tue, Feb 08, 2022 at 10:05:08PM +0800, Huang Jianan wrote: > Changes since v2: > - sync up with erofs-utils 1.4; > - update lib/lz4 to v1.8.3; > - add test for filesystem functions; > > Changes since v1: > - fix the inconsistency between From and SoB; > - add missing license header; > > Huang Jianan (5): > fs/erofs: add erofs filesystem support > lib/lz4: update LZ4 decompressor module > fs/erofs: add lz4 decompression support > fs/erofs: add filesystem commands > test/py: Add tests for the erofs > > MAINTAINERS | 9 + > cmd/Kconfig | 6 + > cmd/Makefile| 1 + > cmd/erofs.c | 42 ++ > configs/sandbox_defconfig | 1 + > fs/Kconfig | 2 + > fs/Makefile | 1 + > fs/erofs/Kconfig| 21 + > fs/erofs/Makefile | 9 + > fs/erofs/data.c | 311 + > fs/erofs/decompress.c | 78 > fs/erofs/decompress.h | 24 + > fs/erofs/erofs_fs.h | 436 ++ > fs/erofs/fs.c | 267 +++ > fs/erofs/internal.h | 313 + > fs/erofs/namei.c| 252 +++ > fs/erofs/super.c| 105 + > fs/erofs/zmap.c | 601 > fs/fs.c | 22 + > include/erofs.h | 19 + > include/fs.h| 1 + > include/u-boot/lz4.h| 49 ++ > lib/lz4.c | 679 > lib/lz4_wrapper.c | 23 +- > test/py/tests/test_fs/test_erofs.py | 211 + > 25 files changed, 3268 insertions(+), 215 deletions(-) > create mode 100644 cmd/erofs.c > create mode 100644 fs/erofs/Kconfig > create mode 100644 fs/erofs/Makefile > create mode 100644 fs/erofs/data.c > create mode 100644 fs/erofs/decompress.c > create mode 100644 fs/erofs/decompress.h > create mode 100644 fs/erofs/erofs_fs.h > create mode 100644 fs/erofs/fs.c > create mode 100644 fs/erofs/internal.h > create mode 100644 fs/erofs/namei.c > create mode 100644 fs/erofs/super.c > create mode 100644 fs/erofs/zmap.c > create mode 100644 include/erofs.h > create mode 100644 test/py/tests/test_fs/test_erofs.py > > -- > 2.25.1
Re: [PATCH v2 0/3] fs/erofs: new filesystem
Hi Jianan, On Wed, Aug 25, 2021 at 06:40:42PM -0400, Tom Rini wrote: > On Mon, Aug 23, 2021 at 08:36:43PM +0800, Huang Jianan wrote: > > > From: Huang Jianan > > > > Add erofs filesystem support. > > > > The code is adapted from erofs-utils in order to reduce maintenance > > burden and keep with the latest feature. > > > > Changes since v1: > > - fix the inconsistency between From and SoB (Bin Meng); > > - add missing license header; > > > > Huang Jianan (3): > > fs/erofs: add erofs filesystem support > > fs/erofs: add lz4 1.8.3 decompressor > > fs/erofs: add lz4 decompression support > > Aside from what I've just now sent, can you please extend the existing > py/tests/ to cover basic functionality here, ensure they run on sandbox > and in CI? Thanks. Any further progress on this work? At least sync it up with erofs-utils 1.4? Thanks, Gao Xiang > > -- > Tom
Re: [PATCH v2 1/3] fs/erofs: add erofs filesystem support
On Mon, Aug 30, 2021 at 12:06:46PM -0400, Tom Rini wrote: > On Mon, Aug 30, 2021 at 11:31:28PM +0800, Huang Jianan wrote: > > 在 2021/8/30 21:27, Huang Jianan 写道: > > > > > > > > > 在 2021/8/26 6:39, Tom Rini 写道: > > > > On Mon, Aug 23, 2021 at 08:36:44PM +0800, Huang Jianan wrote: > > > > > > > > > From: Huang Jianan > > > > > > > > > > This patch mainly deals with uncompressed files. > > > > > > > > > > Signed-off-by: Huang Jianan > > > > > --- > > > > > fs/Kconfig | 1 + > > > > > fs/Makefile | 1 + > > > > > fs/erofs/Kconfig | 12 ++ > > > > > fs/erofs/Makefile | 7 + > > > > > fs/erofs/data.c | 124 ++ > > > > > fs/erofs/erofs_fs.h | 384 > > > > > > > > > > fs/erofs/fs.c | 231 ++ > > > > > fs/erofs/internal.h | 203 +++ > > > > > fs/erofs/namei.c | 238 +++ > > > > > fs/erofs/super.c | 65 > > > > > fs/fs.c | 22 +++ > > > > > include/erofs.h | 19 +++ > > > > > include/fs.h | 1 + > > > > > 13 files changed, 1308 insertions(+) > > > > > create mode 100644 fs/erofs/Kconfig > > > > > create mode 100644 fs/erofs/Makefile > > > > > create mode 100644 fs/erofs/data.c > > > > > create mode 100644 fs/erofs/erofs_fs.h > > > > > create mode 100644 fs/erofs/fs.c > > > > > create mode 100644 fs/erofs/internal.h > > > > > create mode 100644 fs/erofs/namei.c > > > > > create mode 100644 fs/erofs/super.c > > > > > create mode 100644 include/erofs.h > > > > Do the style problems checkpatch.pl complains about here match what's in > > > > the linux kernel? I expect at lease some of them come from using custom > > > > debug/etc macros rather than the standard logging functions. Thanks. > > > > > > The code is mainly come from erofs-utils, thems it has the same problem, > > > i > > > will fix it ASAP. > > > > > > Thanks, > > > Jianan > > > > > I have checked checkpatch.pl complains, some need to be fixed, and some > > come frome using custom macros. It seems that there are still some warnings > > that are inconsistent with the linux kernel, such as : > > > > WARNING: Use 'if (IS_ENABLED(CONFIG...))' instead of '#if or #ifdef' where > > possible > > #835: FILE: fs/erofs/fs.c:224: > > +#ifdef CONFIG_LIB_UUID > > > > WARNING: Possible switch case/default not preceded by break or fallthrough > > comment > > #763: FILE: fs/erofs/zmap.c:489: > > + case Z_EROFS_VLE_CLUSTER_TYPE_NONHEAD: > > > > erofs-utils is written according to the linux kernel coding style, I expect > > this > > part can be consistent in order to reduce maintenance burden and keep > > with the latest feature. > > Yes, please fix what can be easily fixed and still kept in sync with > other projects. Agreed, erofs-utils follows linux kernel style. Maybe we could fix both together if easily fixed... Thanks, Gao Xiang > > -- > Tom
Re: [PATCH v2 0/3] fs/erofs: new filesystem
Hi U-Boot folks, On Mon, Aug 23, 2021 at 08:36:43PM +0800, Huang Jianan wrote: > From: Huang Jianan > > Add erofs filesystem support. > > The code is adapted from erofs-utils in order to reduce maintenance > burden and keep with the latest feature. > > Changes since v1: > - fix the inconsistency between From and SoB (Bin Meng); > - add missing license header; > > Huang Jianan (3): > fs/erofs: add erofs filesystem support > fs/erofs: add lz4 1.8.3 decompressor > fs/erofs: add lz4 decompression support Could someone take some time looking into this? I think adding erofs support to U-Boot is useful for booting with erofs. And keep sync with erofsfuse code in erofs-utils is a good strategy for latest feature. Thanks in advance. Thanks, Gao Xiang > > fs/Kconfig| 1 + > fs/Makefile | 1 + > fs/erofs/Kconfig | 12 + > fs/erofs/Makefile | 10 + > fs/erofs/data.c | 206 > fs/erofs/decompress.c | 74 ++ > fs/erofs/decompress.h | 29 +++ > fs/erofs/erofs_fs.h | 384 ++ > fs/erofs/fs.c | 231 ++ > fs/erofs/internal.h | 203 > fs/erofs/lz4.c| 534 ++ > fs/erofs/lz4.h| 5 + > fs/erofs/namei.c | 238 +++ > fs/erofs/super.c | 65 + > fs/erofs/zmap.c | 517 > fs/fs.c | 22 ++ > include/erofs.h | 19 ++ > include/fs.h | 1 + > 18 files changed, 2552 insertions(+) > create mode 100644 fs/erofs/Kconfig > create mode 100644 fs/erofs/Makefile > create mode 100644 fs/erofs/data.c > create mode 100644 fs/erofs/decompress.c > create mode 100644 fs/erofs/decompress.h > create mode 100644 fs/erofs/erofs_fs.h > create mode 100644 fs/erofs/fs.c > create mode 100644 fs/erofs/internal.h > create mode 100644 fs/erofs/lz4.c > create mode 100644 fs/erofs/lz4.h > create mode 100644 fs/erofs/namei.c > create mode 100644 fs/erofs/super.c > create mode 100644 fs/erofs/zmap.c > create mode 100644 include/erofs.h > > -- > 2.25.1
