Re: [PATCH btrfs-progs] btrfs-progs: do not fail when offset of a ROOT_ITEM is not -1
On Tue, Feb 09, 2021 at 06:34:06PM +0100, 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 other value than -1, though. This can happen for > example if a subvolume is renamed: > > $ btrfs subvolume create X && sync > Create subvolume './X' > $ btrfs inspect-internal dump-tree /dev/root | grep -B 2 'name: X$ > location key (270 ROOT_ITEM 18446744073709551615) type DIR > transid 283 data_len 0 name_len 1 > name: X > $ mv X Y && sync > $ btrfs inspect-internal dump-tree /dev/root | grep -B 2 'name: Y$ > location key (270 ROOT_ITEM 0) type DIR > transid 285 data_len 0 name_len 1 > name: Y > > As can be seen the offset changed from -1ULL to 0. > > Do not fail in this case. > > Signed-off-by: Marek Behún > Cc: David Sterba > Cc: Qu Wenruo > Cc: Tom Rini Added to devel, thanks.
Re: [PATCH] fs: btrfs: Select SHA256 in Kconfig
On Wed, Jan 27, 2021 at 08:14:31PM +0800, Qu Wenruo wrote:
>
>
> 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 leads to compilation errors:
> >> fs/built-in.o: In function `hash_sha256':
> >> fs/btrfs/crypto/hash.c:25: undefined reference to `sha256_starts'
> >> fs/btrfs/crypto/hash.c:26: undefined reference to `sha256_update'
> >> fs/btrfs/crypto/hash.c:27: undefined reference to `sha256_finish'
> >>
> >> Signed-off-by: Matthias Brugger
> >
> > So this is a fix for u-boot, got me confused and not for the first time
> > as there's Kconfig and the same fs/btrfs/ directory structure.
> >
> Well, sometimes too unified file structure/code base can also be a problem.
>
> Considering I'm also going to continue cross-porting more code to
> U-boot, any recommendation on this?
> Using different prefix?
If it's a series then please mention u-boot in the cover letter, no need
to change the patches, I'll go check CC if I'm too confused about the
patch.
Re: [PATCH] fs: btrfs: Select SHA256 in Kconfig
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 leads to compilation errors:
> fs/built-in.o: In function `hash_sha256':
> fs/btrfs/crypto/hash.c:25: undefined reference to `sha256_starts'
> fs/btrfs/crypto/hash.c:26: undefined reference to `sha256_update'
> fs/btrfs/crypto/hash.c:27: undefined reference to `sha256_finish'
>
> Signed-off-by: Matthias Brugger
So this is a fix for u-boot, got me confused and not for the first time
as there's Kconfig and the same fs/btrfs/ directory structure.
Re: [PATCH 2/2] uboot: fs/btrfs: Fix LZO false decompression error caused by pending zero
On Thu, Mar 19, 2020 at 03:34:12PM +0100, Matthias Brugger wrote: > > > On 19/03/2020 14:56, David Sterba wrote: > > On Thu, Mar 19, 2020 at 02:33:28PM +0100, Matthias Brugger wrote: > >>> dlen -= out_len; > >>> > >>> res += out_len; > >>> + > >>> + /* > >>> + * If the 4 bytes header does not fit to the rest of the page we > >>> + * have to move to next one, or we read some garbage. > >>> + */ > >>> + mod_page = tot_in % PAGE_SIZE; > >> > >> in U-Boot we use 4K page sizes, but the OS could use another page size > >> (16K or > >> 64k). Would we need to adapt that code to reflect which page size is used > >> on the > >> medium we want to access? > > > > Yes, it is the 'sectorsize' as it's set up in fs_info or it's equivalent > > in uboot. For kernel the page size == sectorsize is kind of implicit and > > verified at mount time. > > > > Does this mean we would need to add a Kconfig option to set the sectorsize in > U-Boot? No, the value depends on the filesystem so it can't be a config option. What I mean is btrfs_super_block::sectorsize, where the superblock is btrfs_info::sb.
Re: [PATCH 2/2] uboot: fs/btrfs: Fix LZO false decompression error caused by pending zero
On Thu, Mar 19, 2020 at 02:33:28PM +0100, Matthias Brugger wrote: > > dlen -= out_len; > > > > res += out_len; > > + > > + /* > > +* If the 4 bytes header does not fit to the rest of the page we > > +* have to move to next one, or we read some garbage. > > +*/ > > + mod_page = tot_in % PAGE_SIZE; > > in U-Boot we use 4K page sizes, but the OS could use another page size (16K or > 64k). Would we need to adapt that code to reflect which page size is used on > the > medium we want to access? Yes, it is the 'sectorsize' as it's set up in fs_info or it's equivalent in uboot. For kernel the page size == sectorsize is kind of implicit and verified at mount time.
