在 2024/4/22 16:45, Qu Wenruo 写道:
[...]
I added a print statement to free_extent_buffer_internal that prints the
start address of the extent_buffer as I'm not sure what to be looking for
here. This print statement is before the decrement.
printf("free_extent_buffer_internal: eb->st
在 2024/4/22 16:07, Sachi King 写道:
Hi,
I've hit a bug with u-boot on my BTRFS filesystem, and I'm fairly certain
it's a bug and not a corruption issue.
A bit of history on the filesystem. It is a fairly new filesystem as it was
being used to give me access to test a wayland application on a
ime should also try to read the whole file? Or that
EFI environment has specified the length to read instead?
Signed-off-by: Sam Edwards
Anyway, the fix looks good to me.
Reviewed-by: Qu Wenruo
Thanks,
Qu
---
fs/btrfs/btrfs.c | 15 ++-
1 file changed, 6 insertions(+), 9
Reviewed-by: Qu Wenruo
Thanks,
Qu
---
fs/btrfs/inode.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index 38e285bf94b0..4691612eda33 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -390,7 +390,7 @@ int btrfs_read_extent_inl
;root" and crashes.
Signed-off-by: Dan Carpenter
Reviewed-by: Qu Wenruo
---
I didn't CC the btrfs mailing list. Perhaps, I should have?
This patch is fine. The function is specific to U-boot, and not utilized
by kernel/btrfs-progs.
Thanks,
Qu
fs/btrfs/subvolume.c | 1 +
1 file
ude headers
*
* Write related functions are kept as we still need to modify dummy extent
For the btrfs part:
Reviewed-by: Qu Wenruo
Thanks,
Qu
ing that booted now fails to
boot)
Fixes: a26a6bedafcf ("fs: btrfs: Introduce btrfs_read_extent_inline() and
btrfs_read_extent_reg()")
Signed-off-by: Dominique Martinet
Reviewed-by: Qu Wenruo
Thanks,
Qu
---
Changes in v2:
- Keep offset decomposition explicit where it is used
- A
On 2023/4/18 11:53, Dominique Martinet wrote:
Qu Wenruo wrote on Tue, Apr 18, 2023 at 11:21:00AM +0800:
No, was just thinking the leading part being a separate loop doesn't
seem to make sense either as the code shouldn't care about sector size
alignemnt but about full extents.
The main
On 2023/4/18 11:07, Dominique Martinet wrote:
Qu Wenruo wrote on Tue, Apr 18, 2023 at 10:53:41AM +0800:
I have a feeling the loop could just be updated to go to the end
`while (cur < end)` as it doesn't seem to care about the end
alignment... Should I update v2 to do that instead?
Y
On 2023/4/18 10:41, Dominique Martinet wrote:
Qu Wenruo wrote on Tue, Apr 18, 2023 at 10:02:00AM +0800:
/* Read the tailing unaligned part*/
Can we remove this part completely?
IIRC if we read until the target end, the unaligned end part can be
completely removed then.
The "
On 2023/4/18 10:05, Dominique Martinet wrote:
Qu Wenruo wrote on Tue, Apr 18, 2023 at 09:58:37AM +0800:
The subject can be changed to "btrfs: fix offset when reading compressed
extents".
The original one is a little too generic.
Ok.
btrfs_file_read()
-> btrfs_re
On 2023/4/18 10:05, Dominique Martinet wrote:
Qu Wenruo wrote on Tue, Apr 18, 2023 at 09:58:37AM +0800:
The subject can be changed to "btrfs: fix offset when reading compressed
extents".
The original one is a little too generic.
Ok.
btrfs_file_read()
-> btrfs_re
On 2023/4/18 09:17, Dominique Martinet wrote:
From: Dominique Martinet
btfs_file_read's truncate path has a comment noting '>0 means no extent'
and bailing out immediately, but the buffer has not been written so
probably needs zeroing out.
This is a theorical fix only and hasn't been
On 2023/4/18 09:17, Dominique Martinet wrote:
From: Dominique Martinet
btrfs_file_read main 'aligned read' loop would limit the last read to
the aligned end even if the data is present in the extent: there is no
reason not to read the data that we know will be presented correctly.
If that
On 2023/4/18 09:17, Dominique Martinet wrote:
From: Dominique Martinet
The subject can be changed to "btrfs: fix offset when reading compressed
extents".
The original one is a little too generic.
btrfs_read_extent_reg correctly computed the extent offset in the
BTRFS_COMPRESS_NONE
don't limit the
returned length at all, and even for other profiles, we can still return
a length much larger than the requested one.
[FIX]
Properly clamp the returned length, preventing it from returning a much
larger range than expected.
Reported-by: Andreas Schwab
Signed-off-by: Qu Wenruo
--
On 2023/2/13 00:20, Andreas Schwab wrote:
When I print ce->size in __btrfs_map_block, it is almost always
1073741824, which looks bogus.
Can you provide the image of that filesystem?
Thanks,
Qu
.
For multi-device RAID0/RAID10/RAID5/6, we don't support them until we
can scan all devices in U-boot...
Thanks,
Qu
Thanks,
Sam Winchenbach
-Original Message-
From: U-Boot On Behalf Of Qu Wenruo
Sent: Thursday, December 29, 2022 7:01 PM
To: Heinrich Schuchardt ; Sam Winchenbach
s
=> md5sum 0 0x2
md5 for ... 0001 ==> d48858312a922db7eb86377f638dbc9f
^^^ Above md5sum also matches.
Reported-by: Sam Winchenbach
Signed-off-by: Qu Wenruo
---
fs/btrfs/disk-io.c | 49 +-
1 file changed, 27 insertions(+), 22 dele
n't
correct. Any pointers on how this code is supposed to work would be
greatly appreciated.
Thanks.
Thanks for reporting the issue
$ scripts/get_maintainer.pl -f fs/btrfs/volumes.c
suggests to include
"Marek Behún" (maintainer:BTRFS)
Qu Wenruo (reviewer:BTRFS)
linux-bt...@vger.ker
On 2022/9/28 23:23, Pankaj Raghav wrote:
This line probably got in by mistake as there is no fs_mutex member in
the btrfs_fs_info struct.
Signed-off-by: Pankaj Raghav
Reviewed-by: Qu Wenruo
Thanks,
Qu
---
For UBOOT.
The patch I sent the first time is not showing up in the uboot
On 2022/9/27 18:49, Pankaj Raghav wrote:
Which branch is the code based on?
I actually cloned it from u-boot github master.
https://github.com/u-boot/u-boot/blob/f117c54cc83e3c519883edb5a48062644d38c443/fs/btrfs/disk-io.c#L785
I don't believe it's upstream, as such compiling error
On 2022/9/27 18:39, Qu Wenruo wrote:
On 2022/9/27 17:55, Pankaj Raghav wrote:
This line probably got in by mistake as there is no fs_mutex member in
the btrfs_fs_info struct.
Signed-off-by: Pankaj Raghav
Which branch is the code based on?
I don't believe it's upstream
On 2022/9/27 17:55, Pankaj Raghav wrote:
This line probably got in by mistake as there is no fs_mutex member in
the btrfs_fs_info struct.
Signed-off-by: Pankaj Raghav
Which branch is the code based on?
I don't believe it's upstream, as such compiling error should be exposed
very easily.
: Huang Jianan
Cc: linux-er...@lists.ozlabs.org
Signed-off-by: Qu Wenruo
---
fs/erofs/internal.h | 1 +
fs/erofs/super.c| 6 ++
fs/fs.c | 2 +-
include/erofs.h | 1 +
4 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/fs/erofs/internal.h b/fs/erofs/internal.h
index
Currently ubifs doesn't support unaligned read offset, thanks to the
recent _fs_read() work to handle unaligned read, we only need to
implement ubifs_get_blocksize() to take advantage of it.
Now ubifs can do unaligned read without any problem.
Signed-off-by: Qu Wenruo
---
Unfortunately I can
Just implement fat_get_blocksize() for fat, so that fat_read_file()
always get a block aligned read range.
Unfortunately I'm not experienced enough to cleanup the fat code, thus
further cleanup is appreciated.
Cc: Tom Rini
Signed-off-by: Qu Wenruo
---
fs/fat/fat.c | 13 +
fs/fs.c
and unaligned range and
compare the output with md5sum.
Cc: Marek Behun
Cc: linux-bt...@vger.kernel.org
Signed-off-by: Qu Wenruo
---
fs/btrfs/btrfs.c | 10
fs/btrfs/inode.c | 89 +++-
fs/fs.c | 130 ---
include/btrfs.h
Just add ext4_get_blocksize() and a new assert() in ext4fs_read_file().
Signed-off-by: Qu Wenruo
---
Several cleanup candicate:
1. ext_fs->blksz is never populated, thus it's always 0
We can not easily grab blocksize just like btrfs in this case.
Thus we have to go the same calculat
: Read range beyond file size, offset 8192 file size 5120
Failed to load '5m_origin'
Signed-off-by: Qu Wenruo
---
fs/btrfs/btrfs.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/fs/btrfs/btrfs.c b/fs/btrfs/btrfs.c
index 309cd595d37d..74a992fa012d 100644
--- a/fs/btrfs/btrfs.c
+++ b/fs
X]
Fix it by just always do the file size check.
In fact btrfs_size() always follow soft link, thus it will return the
real file size correctly.
Signed-off-by: Qu Wenruo
---
fs/btrfs/btrfs.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/fs/btrfs/btrfs.c b/fs
That function is only utilized inside fat driver, unexport it.
Signed-off-by: Qu Wenruo
---
fs/fat/fat.c | 4 ++--
include/fat.h | 2 --
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/fs/fat/fat.c b/fs/fat/fat.c
index df9ea2c028fc..dcceccbcee0a 100644
--- a/fs/fat/fat.c
+++ b
) 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: btr
On 2022/8/6 05:14, Tom Rini wrote:
On Tue, Jul 26, 2022 at 01:22:09PM +0800, Qu Wenruo wrote:
That function is only utilized inside fat driver, unexport it.
Signed-off-by: Qu Wenruo
Unfortunately, the series fails CI:
https://source.denx.de/u-boot/u-boot/-/jobs/478838
OK, it's a bug
: Huang Jianan
Cc: linux-er...@lists.ozlabs.org
Signed-off-by: Qu Wenruo
Reviewed-by: Huang Jianan
---
fs/erofs/internal.h | 1 +
fs/erofs/super.c| 6 ++
fs/fs.c | 2 +-
include/erofs.h | 1 +
4 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/fs/erofs/internal.h b
Currently ubifs doesn't support unaligned read offset, thanks to the
recent _fs_read() work to handle unaligned read, we only need to
implement ubifs_get_blocksize() to take advantage of it.
Now ubifs can do unaligned read without any problem.
Signed-off-by: Qu Wenruo
---
fs/fs.c
Just implement fat_get_blocksize() for fat, so that fat_read_file()
always get a block aligned read range.
Unfortunately I'm not experienced enough to cleanup the fat code, thus
further cleanup is appreciated.
Cc: Tom Rini
Signed-off-by: Qu Wenruo
---
fs/fat/fat.c | 13 +
fs/fs.c
Just add ext4_get_blocksize() and a new assert() in ext4fs_read_file().
Signed-off-by: Qu Wenruo
---
fs/ext4/ext4fs.c | 22 ++
fs/fs.c | 2 +-
include/ext4fs.h | 1 +
3 files changed, 24 insertions(+), 1 deletion(-)
diff --git a/fs/ext4/ext4fs.c b/fs/ext4
and unaligned range and
compare the output with md5sum.
Cc: Marek Behun
Cc: linux-bt...@vger.kernel.org
Signed-off-by: Qu Wenruo
---
fs/btrfs/btrfs.c | 10
fs/btrfs/inode.c | 89 +++-
fs/fs.c | 130 ---
include/btrfs.h
: Read range beyond file size, offset 8192 file size 5120
Failed to load '5m_origin'
Signed-off-by: Qu Wenruo
---
fs/btrfs/btrfs.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/fs/btrfs/btrfs.c b/fs/btrfs/btrfs.c
index 9145727058d4..bf9e1f2f17cf 100644
--- a/fs/btrfs/btrfs.c
+++ b/fs
X]
Fix it by just always do the file size check.
In fact btrfs_size() always follow soft link, thus it will return the
real file size correctly.
Signed-off-by: Qu Wenruo
---
fs/btrfs/btrfs.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/fs/btrfs/btrfs.c b/fs
That function is only utilized inside fat driver, unexport it.
Signed-off-by: Qu Wenruo
---
fs/fat/fat.c | 4 ++--
include/fat.h | 2 --
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/fs/fat/fat.c b/fs/fat/fat.c
index df9ea2c028fc..dcceccbcee0a 100644
--- a/fs/fat/fat.c
+++ b
add block aligned offset support.
- Semihostfs
- Sandboxfs
They all use read() directly, no need to do alignment check at all.
Extra testing/feedback is always appreciated.
Qu Wenruo (8):
fs: fat: unexport file_fat_read_at()
fs: btrfs: fix a bug which no data get read if the length is
On 2022/7/26 06:28, Tom Rini wrote:
On Wed, Jun 29, 2022 at 07:38:22PM +0800, Qu Wenruo wrote:
That function is only utilized inside fat driver, unexport it.
Signed-off-by: Qu Wenruo
The series has a fails to build on nokia_rx51:
https://source.denx.de/u-boot/u-boot/-/jobs/471877#L483
On 2022/6/30 18:06, Simon Glass wrote:
On Tue, 28 Jun 2022 at 01:28, Qu Wenruo wrote:
This is to make sandboxfs to report blocksize it supports for
_fs_read() to handle unaligned read.
Unlike all other fses, sandboxfs can handle unaligned read/write without
any problem since it's calling
Currently ubifs doesn't support unaligned read offset, thanks to the
recent _fs_read() work to handle unaligned read, we only need to
implement ubifs_get_blocksize() to take advantage of it.
Now ubifs can do unaligned read without any problem.
Signed-off-by: Qu Wenruo
---
Unfortunately I can
: Huang Jianan
Cc: linux-er...@lists.ozlabs.org
Signed-off-by: Qu Wenruo
---
fs/erofs/internal.h | 1 +
fs/erofs/super.c| 6 ++
fs/fs.c | 2 +-
include/erofs.h | 1 +
4 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/fs/erofs/internal.h b/fs/erofs/internal.h
index
Just add ext4_get_blocksize() and a new assert() in ext4fs_read_file().
Signed-off-by: Qu Wenruo
---
Several cleanup candicate:
1. ext_fs->blksz is never populated, thus it's always 0
We can not easily grab blocksize just like btrfs in this case.
Thus we have to go the same calculat
and unaligned range and
compare the output with md5sum.
Cc: Marek Behun
Cc: linux-bt...@vger.kernel.org
Signed-off-by: Qu Wenruo
---
fs/btrfs/btrfs.c | 10
fs/btrfs/inode.c | 89 +++-
fs/fs.c | 130 ---
include/btrfs.h
Just implement fat_get_blocksize() for fat, so that fat_read_file()
always get a block aligned read range.
Unfortunately I'm not experienced enough to cleanup the fat code, thus
further cleanup is appreciated.
Cc: Tom Rini
Signed-off-by: Qu Wenruo
---
fs/fat/fat.c | 13 +
fs/fs.c
: Read range beyond file size, offset 8192 file size 5120
Failed to load '5m_origin'
Signed-off-by: Qu Wenruo
---
fs/btrfs/btrfs.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/fs/btrfs/btrfs.c b/fs/btrfs/btrfs.c
index 9145727058d4..bf9e1f2f17cf 100644
--- a/fs/btrfs/btrfs.c
+++ b/fs
X]
Fix it by just always do the file size check.
In fact btrfs_size() always follow soft link, thus it will return the
real file size correctly.
Signed-off-by: Qu Wenruo
---
fs/btrfs/btrfs.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/fs/btrfs/btrfs.c b/fs
That function is only utilized inside fat driver, unexport it.
Signed-off-by: Qu Wenruo
---
fs/fat/fat.c | 4 ++--
include/fat.h | 2 --
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/fs/fat/fat.c b/fs/fat/fat.c
index df9ea2c028fc..dcceccbcee0a 100644
--- a/fs/fat/fat.c
+++ b
ort.
- Semihostfs
- Sandboxfs
They all use read() directly, no need to do alignment check at all.
Extra testing/feedback is always appreciated.
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 ra
On 2022/6/28 22:17, Tom Rini wrote:
On Tue, Jun 28, 2022 at 03:28:00PM +0800, Qu Wenruo wrote:
[BACKGROUND]
Unlike FUSE/Kernel which always pass aligned read range, U-boot fs code
just pass the request range to underlying fses.
Under most case, this works fine, as U-boot only really needs
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 o
: Huang Jianan
Cc: linux-er...@lists.ozlabs.org
Signed-off-by: Qu Wenruo
---
fs/erofs/internal.h | 1 +
fs/erofs/super.c| 6 ++
fs/fs.c | 2 +-
include/erofs.h | 1 +
4 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/fs/erofs/internal.h b/fs/erofs/internal.h
index
Currently ubifs doesn't support unaligned read offset, thanks to the
recent _fs_read() work to handle unaligned read, we only need to
implement ubifs_get_blocksize() to take advantage of it.
Now ubifs can do unaligned read without any problem.
Signed-off-by: Qu Wenruo
---
fs/fs.c
testing of _fs_read() much easier.
Cc: Simon Glass
Signed-off-by: Qu Wenruo
---
arch/sandbox/cpu/os.c | 11 +++
fs/fs.c| 2 +-
fs/sandbox/sandboxfs.c | 14 ++
include/os.h | 8
include/sandboxfs.h| 1 +
5 files changed, 35 insertions
Just implement fat_get_blocksize() for fat, so that fat_read_file()
always get a block aligned read range.
Unfortunately I'm not experienced enough to cleanup the fat code, thus
further cleanup is appreciated.
Cc: Tom Rini
Signed-off-by: Qu Wenruo
---
fs/fat/fat.c | 13 +
fs/fs.c
to clean them up is
appreciated.
Cc: Tom Rini
Signed-off-by: Qu Wenruo
---
fs/ext4/ext4fs.c | 11 +++
fs/fs.c | 2 +-
include/ext4fs.h | 1 +
3 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/fs/ext4/ext4fs.c b/fs/ext4/ext4fs.c
index 4c89152ce4ad..be2680994d8b 100644
+ @len is, then copy the requested range
in the buffer.
This has been tested with a proper randomly populated btrfs file, then
tried in sandbox mode with different aligned and unaligned range and
compare the output with md5sum.
Cc: Marek Behun
Cc: linux-bt...@vger.kernel.org
Signed-off-by: Qu
n (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
---
fs/fs.c | 25 +
1 file changed, 21 insertions(+), 4 deletions(-)
diff --git a/fs/fs.c b/fs/f
That function is only utilized inside fat driver, unexport it.
Signed-off-by: Qu Wenruo
---
fs/fat/fat.c | 4 ++--
include/fat.h | 2 --
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/fs/fat/fat.c b/fs/fat/fat.c
index df9ea2c028fc..dcceccbcee0a 100644
--- a/fs/fat/fat.c
+++ b
for stat() call.
Extra testing/feedback is always appreciated.
Qu Wenruo (8):
fs: fat: unexport file_fat_read_at()
fs: always get the file size in _fs_read()
fs: btrfs: move the unaligned read code to _fs_read() for btrfs
fs: ext4: rely on _fs_read() to pass block aligned range
On 2022/5/11 06:48, Qu Wenruo wrote:
On 2022/5/11 03:43, Heinrich Schuchardt wrote:
After returning if ret <= 0 we know that ret > 0. No need to check it.
Signed-off-by: Heinrich Schuchardt
Reviewed-by: Qu Wenruo
Just to mention for other guys in the btrfs list, this patch is
On 2022/5/11 03:43, Heinrich Schuchardt wrote:
After returning if ret <= 0 we know that ret > 0. No need to check it.
Signed-off-by: Heinrich Schuchardt
Reviewed-by: Qu Wenruo
Thanks,
Qu
---
fs/btrfs/inode.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
Hi U-boot fs guys,
With my previous rework on U-boot btrfs, and my own btrfs-fuse project,
it turns out that, although U-boot implements its fs with a very fuse
like interface, there are still some quality-of-life features missing.
One of the most obvious one is making each fs to handle
)
^~
Include file asm/unaligned.h contains arch specific macros and functions
for unaligned access as opposite to linux/unaligned le_byteshift.h which
contains macros and functions specific to little endian systems only.
Signed-off-by: Pali Rohár
Reviewed-by: Qu Wenruo
Thanks,
Qu
On 2021/12/27 14:11, Qu Wenruo wrote:
[BUG]
When passing a btrfs with NO_HOLE feature to U-boot, and if one file
contains holes, then the hash of the file is not correct in U-boot:
# mkfs.btrfs -f test.img # Since v5.15, mkfs defaults to NO_HOLES
# mount test.img /mnt/btrfs
The code is cross-ported from BLAKE2 reference implementation
(https://github.com/BLAKE2/BLAKE2).
With minimal change to remove unused macros/features.
Currently there is only one user inside U-boot (btrfs), and since it
only utilize BLAKE2B, all other favors are all removed.
Signed-off-by: Qu
Now btrfs can utilize the newly intorudced BLAKE2 hash.
Signed-off-by: Qu Wenruo
---
fs/btrfs/Kconfig | 1 +
fs/btrfs/crypto/hash.c | 14 ++
fs/btrfs/crypto/hash.h | 1 +
fs/btrfs/disk-io.c | 2 ++
4 files changed, 18 insertions(+)
diff --git a/fs/btrfs/Kconfig b/fs
far the data is still correct
- Read 4K data from disk to file offset [4K, 8K)
We didn't skip the 4K hole, but read the data at file offset [8K, 12K)
into file offset [4K, 8K).
This causes the checksum mismatch.
[FIX]
Add extra check to skip to the next non-hole range after
lookup_data_e
On 2021/12/17 07:45, Qu Wenruo wrote:
On 2021/12/17 07:05, Marek Behún wrote:
Hello Qu and others,
one of the points of Qu's reimplementation of U-Boot's btrfs code that
made it somehow synced with btrfs-progs, was that the old
implementation was, quote
pretty different from btrfs
On 2021/12/17 07:05, Marek Behún wrote:
Hello Qu and others,
one of the points of Qu's reimplementation of U-Boot's btrfs code that
made it somehow synced with btrfs-progs, was that the old
implementation was, quote
pretty different from btrfs-progs nor kernel, making it pretty hard to
On 2021/9/17 22:25, Mark Kettenis wrote:
Date: Fri, 17 Sep 2021 19:42:29 +0800
Content-Language: en-US
On 2021/9/17 19:34, Mark Kettenis wrote:
From: Qu Wenruo
Date: Fri, 17 Sep 2021 19:02:35 +0800
When booting using U-boot -> systemd-boot (EFI payload) -> kernel on
RK3399, system
On 2021/9/17 19:45, Lennart Poettering wrote:
On Fr, 17.09.21 19:25, Qu Wenruo (w...@suse.com) wrote:
Hi,
I'm recently testing booting my RK3399 boards with the following boot
sequence:
U-boot -> systemd-boot (EFI payload) -> kernel
Which provides much more flex than plain extlinu
On 2021/9/17 19:45, Lennart Poettering wrote:
On Fr, 17.09.21 19:25, Qu Wenruo (w...@suse.com) wrote:
Hi,
I'm recently testing booting my RK3399 boards with the following boot
sequence:
U-boot -> systemd-boot (EFI payload) -> kernel
Which provides much more flex than plain extlinu
On 2021/9/17 19:34, Mark Kettenis wrote:
From: Qu Wenruo
Date: Fri, 17 Sep 2021 19:02:35 +0800
When booting using U-boot -> systemd-boot (EFI payload) -> kernel on
RK3399, systemd-boot by some bug can't execute its "devicetree" key
correctly to load its proper dtb from file
Hi,
I'm recently testing booting my RK3399 boards with the following boot
sequence:
U-boot -> systemd-boot (EFI payload) -> kernel
Which provides much more flex than plain extlinux conf from U-boot.
(More choice, easier to write config, runtime kernel change).
So far "kernel" and "initramfs"
.
So this patch will workaround the problem by appending common linux dtbs
directory to the existing "efi_dtb_prefixes" so that for systemd-boot it
can use the existing fdt and boot properly.
Signed-off-by: Qu Wenruo
---
include/config_distro_bootcmd.h | 2 +-
1 file changed, 1 insertion(+),
Hi,
Is there any way to change the $scan_dev_for_boot search sequence?
Currently it always go extlinux first, then scripts, and finally EFI.
Normally this is completely fine, as one system should only have one of
these, thus search sequence makes no difference.
But for certain distros,
On 2021/9/1 下午9:48, Matthias Brugger wrote:
On 01/09/2021 13:36, Tom Rini wrote:
On Wed, Sep 01, 2021 at 01:28:30PM +0200, Matthias Brugger wrote:
Hi Tom,
On 02/08/2021 01:06, Qu Wenruo wrote:
On 2021/8/2 上午4:52, Matwey V. Kornilov wrote:
BTRFS volume consists of a number
.
Turn it into a debug message.
Signed-off-by: Simon Glass
Reviewed-by: Qu Wenruo
Thanks,
Qu
---
fs/btrfs/disk-io.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index 349411c3ccd..1b69346e231 100644
--- a/fs/btrfs/disk-io.c
bvolume as the filesystem root to overcome
mentioned issues.
Reference: https://bugzilla.suse.com/show_bug.cgi?id=1185656
Signed-off-by: Matwey V. Kornilov
Reviewed-by: Qu Wenruo
Thanks,
Qu
---
fs/btrfs/disk-io.c | 38 +++---
1 file changed, 35 insertions(+), 3
On 2021/5/4 上午7:10, Simon Glass wrote:
Use the common function to avoid code duplication.
Signed-off-by: Simon Glass
Acked-by: Qu Wenruo
Thanks,
Qu
---
(no changes since v1)
fs/btrfs/compression.c | 51 +-
1 file changed, 5 insertions(+), 46
ine and
regular compressed extents.
Reported-by: Matwey Kornilov
Link: https://bugzilla.suse.com/show_bug.cgi?id=1183717
Fixes: a26a6bedafcf ("fs: btrfs: Introduce btrfs_read_extent_inline() and
btrfs_read_extent_reg()")
Signed-off-by: Qu Wenruo
---
Changelog:
v2:
- Fix the bug for regul
wey Kornilov
Link: https://bugzilla.suse.com/show_bug.cgi?id=1183717
Fixes: a26a6bedafcf ("fs: btrfs: Introduce btrfs_read_extent_inline() and
btrfs_read_extent_reg()")
Signed-off-by: Qu Wenruo
---
fs/btrfs/inode.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --g
On 2021/2/11 上午12:21, Marek Behun wrote:
On Wed, 10 Feb 2021 09:20:11 +0800
Qu Wenruo wrote:
You're correct, the kernel is using new schema, btrfs_get_fs_root(),
which only requires root objectid and completely get rid of the
offset/type, which is far less possible to call with wrong
On 2021/2/10 上午9:05, Marek Behun wrote:
On Wed, 10 Feb 2021 08:09:14 +0800
Qu Wenruo wrote:
On 2021/2/10 上午1:33, Marek Behún wrote:
When the btrfs_read_fs_root() function is searching a ROOT_ITEM with
location key offset other than -1, it currently fails via BUG_ON.
The offset can have
On 2021/2/10 上午2:05, Marek Behún wrote:
Skip xattrs in directory listing. U-Boot filesystem drivers do not list
xattrs.
Signed-off-by: Marek Behún
Cc: David Sterba
Cc: Qu Wenruo
Cc: Tom Rini
Reviewed-by: Qu Wenruo
Thanks,
Qu
---
fs/btrfs/btrfs.c | 5 -
1 file changed, 4
dd ("fs: btrfs: Use btrfs_iter_dir() to replace ...")
Cc: David Sterba
Cc: Qu Wenruo
Cc: Tom Rini
Reviewed-by: Qu Wenruo
---
fs/btrfs/btrfs.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/fs/btrfs/btrfs.c b/fs/btrfs/btrfs.c
index 6b4c5feb
we wrongly call
btrfs_read_fs_root() with incorrect offset inside btrfs-progs/uboot?
I believe that would be the proper way to fix.
Thanks,
Qu
Do not fail in this case.
Signed-off-by: Marek Behún
Cc: David Sterba
Cc: Qu Wenruo
Cc: Tom Rini
---
fs/btrfs/disk-io.c | 3 +--
1 file changed, 1
On 2021/1/27 下午8:01, David Sterba wrote:
On Wed, Jan 27, 2021 at 10:42:30AM +0100, matthias@kernel.org wrote:
From: Matthias Brugger
Since commit 565a4147d17a ("fs: btrfs: Add more checksum algorithms")
btrfs uses the sha256 checksum algorithm. But Kconfig lacks to select
it. This
Reviewed-by: Qu Wenruo
Thanks,
Qu
---
fs/btrfs/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/btrfs/Kconfig b/fs/btrfs/Kconfig
index f302b1fbef..2a32f42ad1 100644
--- a/fs/btrfs/Kconfig
+++ b/fs/btrfs/Kconfig
@@ -4,6 +4,7 @@ config FS_BTRFS
select LZO
s
value.
I don't believe U-boot would support btrfs read-write any time soon,
thus the cleanup should be OK.
Reviewed-by: Qu Wenruo
Thanks,
Qu
Signed-off-by: Heinrich Schuchardt
---
fs/btrfs/disk-io.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/fs/btrfs/disk-io.c
On 2020/11/2 下午3:24, Marek Behun wrote:
> On Mon, 2 Nov 2020 08:27:16 +0800
> Qu Wenruo wrote:
>
>> Thus I really tend to believe it's just a bug in coverity.
>> All locations accessing @ii all have its key.type checked to ensure it get
>> filled in the first p
On 2020/11/2 上午8:20, Qu Wenruo wrote:
>
>
> On 2020/11/2 上午7:02, Marek Behun wrote:
>> On Sat, 31 Oct 2020 09:07:50 +0800
>> Qu Wenruo wrote:
>>
>>> In real world, this should not cause problem as we have device number
>>> limit thus it won't
On 2020/11/2 上午7:06, Marek Behun wrote:
> On Sat, 31 Oct 2020 09:07:52 +0800
> Qu Wenruo wrote:
>
>> In show_dir() if we hit file type FT_CHRDEV or FT_BLKDEV, we expect an
>> BTRFS_INODE_ITEM_KEY, and for that case, we should have @ii filled with
>> data read fr
On 2020/11/2 上午7:02, Marek Behun wrote:
> On Sat, 31 Oct 2020 09:07:50 +0800
> Qu Wenruo wrote:
>
>> In real world, this should not cause problem as we have device number
>> limit thus it won't go beyond 4G for a single stripe.
>
> So we can't run into this over
1 - 100 of 206 matches
Mail list logo
