<feed xmlns='http://www.w3.org/2005/Atom'>
<title>u-boot.git/fs, branch v2023.04</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.
</subtitle>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/'/>
<entry>
<title>fs: ext4: check the minimal partition size to mount</title>
<updated>2023-03-22T16:51:14+00:00</updated>
<author>
<name>Patrick Delaunay</name>
<email>patrick.delaunay@foss.st.com</email>
</author>
<published>2023-03-08T08:49:54+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=9905cae65e03335aefcb1ebfab5b7ee62d89f64e'/>
<id>9905cae65e03335aefcb1ebfab5b7ee62d89f64e</id>
<content type='text'>
No need to mount a too small partition to handle a EXT4 file system.

This patch add a test on partition size before to read the
SUPERBLOCK_SIZE buffer and avoid error latter in fs_devread() function.

Signed-off-by: Patrick Delaunay &lt;patrick.delaunay@foss.st.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
No need to mount a too small partition to handle a EXT4 file system.

This patch add a test on partition size before to read the
SUPERBLOCK_SIZE buffer and avoid error latter in fs_devread() function.

Signed-off-by: Patrick Delaunay &lt;patrick.delaunay@foss.st.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>fs: btrfs: limit the mapped length to the original length</title>
<updated>2023-02-23T18:29:19+00:00</updated>
<author>
<name>Qu Wenruo</name>
<email>wqu@suse.com</email>
</author>
<published>2023-02-13T00:37:59+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=511a1303c9cf9663c7d4312e3a0693319f41095b'/>
<id>511a1303c9cf9663c7d4312e3a0693319f41095b</id>
<content type='text'>
[BUG]
There is a bug report that btrfs driver caused hang during file read:

  This breaks btrfs on the HiFive Unmatched.

  =&gt; pci enum
  PCIE-0: Link up (Gen1-x8, Bus0)
  =&gt; nvme scan
  =&gt; load nvme 0:2 0x8c000000 /boot/dtb/sifive/hifive-unmatched-a00.dtb
  [hangs]

[CAUSE]
The reporter provided some debug output:

  read_extent_data: cur=615817216, orig_len=16384, cur_len=16384
  read_extent_data: btrfs_map_block: cur_len=479944704; ret=0
  read_extent_data: ret=0
  read_extent_data: cur=615833600, orig_len=4096, cur_len=4096
  read_extent_data: btrfs_map_block: cur_len=479928320; ret=0

Note the second and the last line, the @cur_len is 450+MiB, which is
almost a chunk size.

And inside __btrfs_map_block(), we limits the returned value to stripe
length, but that's depending on the chunk type:

	if (map-&gt;type &amp; (BTRFS_BLOCK_GROUP_RAID0 | BTRFS_BLOCK_GROUP_RAID1 |
			 BTRFS_BLOCK_GROUP_RAID1C3 | BTRFS_BLOCK_GROUP_RAID1C4 |
			 BTRFS_BLOCK_GROUP_RAID5 | BTRFS_BLOCK_GROUP_RAID6 |
			 BTRFS_BLOCK_GROUP_RAID10 |
			 BTRFS_BLOCK_GROUP_DUP)) {
		/* we limit the length of each bio to what fits in a stripe */
		*length = min_t(u64, ce-&gt;size - offset,
			      map-&gt;stripe_len - stripe_offset);
	} else {
		*length = ce-&gt;size - offset;
	}

This means, if the chunk is SINGLE profile, then we 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 &lt;schwab@linux-m68k.org&gt;
Signed-off-by: Qu Wenruo &lt;wqu@suse.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[BUG]
There is a bug report that btrfs driver caused hang during file read:

  This breaks btrfs on the HiFive Unmatched.

  =&gt; pci enum
  PCIE-0: Link up (Gen1-x8, Bus0)
  =&gt; nvme scan
  =&gt; load nvme 0:2 0x8c000000 /boot/dtb/sifive/hifive-unmatched-a00.dtb
  [hangs]

[CAUSE]
The reporter provided some debug output:

  read_extent_data: cur=615817216, orig_len=16384, cur_len=16384
  read_extent_data: btrfs_map_block: cur_len=479944704; ret=0
  read_extent_data: ret=0
  read_extent_data: cur=615833600, orig_len=4096, cur_len=4096
  read_extent_data: btrfs_map_block: cur_len=479928320; ret=0

Note the second and the last line, the @cur_len is 450+MiB, which is
almost a chunk size.

And inside __btrfs_map_block(), we limits the returned value to stripe
length, but that's depending on the chunk type:

	if (map-&gt;type &amp; (BTRFS_BLOCK_GROUP_RAID0 | BTRFS_BLOCK_GROUP_RAID1 |
			 BTRFS_BLOCK_GROUP_RAID1C3 | BTRFS_BLOCK_GROUP_RAID1C4 |
			 BTRFS_BLOCK_GROUP_RAID5 | BTRFS_BLOCK_GROUP_RAID6 |
			 BTRFS_BLOCK_GROUP_RAID10 |
			 BTRFS_BLOCK_GROUP_DUP)) {
		/* we limit the length of each bio to what fits in a stripe */
		*length = min_t(u64, ce-&gt;size - offset,
			      map-&gt;stripe_len - stripe_offset);
	} else {
		*length = ce-&gt;size - offset;
	}

This means, if the chunk is SINGLE profile, then we 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 &lt;schwab@linux-m68k.org&gt;
Signed-off-by: Qu Wenruo &lt;wqu@suse.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Correct SPL use of FS_EROFS</title>
<updated>2023-02-10T12:41:39+00:00</updated>
<author>
<name>Simon Glass</name>
<email>sjg@chromium.org</email>
</author>
<published>2023-02-05T22:40:03+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=0e56bc1668f334c648bc13e40cb99e326f727eb3'/>
<id>0e56bc1668f334c648bc13e40cb99e326f727eb3</id>
<content type='text'>
This converts 1 usage of this option to the non-SPL form, since there is
no SPL_FS_EROFS defined in Kconfig

Signed-off-by: Simon Glass &lt;sjg@chromium.org&gt;
Reviewed-by: Huang Jianan &lt;jnhuang95@gmail.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This converts 1 usage of this option to the non-SPL form, since there is
no SPL_FS_EROFS defined in Kconfig

Signed-off-by: Simon Glass &lt;sjg@chromium.org&gt;
Reviewed-by: Huang Jianan &lt;jnhuang95@gmail.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>log: Add a category for filesystems</title>
<updated>2023-02-06T18:04:53+00:00</updated>
<author>
<name>Simon Glass</name>
<email>sjg@chromium.org</email>
</author>
<published>2023-01-28T22:00:16+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=4f6daaca0fa225e785bd8293d7c5c88d9ff0b1bd'/>
<id>4f6daaca0fa225e785bd8293d7c5c88d9ff0b1bd</id>
<content type='text'>
Sometimes it is useful to log things related to filesystems. Add a new
category and place it at the top of one of the FAT files.

Signed-off-by: Simon Glass &lt;sjg@chromium.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Sometimes it is useful to log things related to filesystems. Add a new
category and place it at the top of one of the FAT files.

Signed-off-by: Simon Glass &lt;sjg@chromium.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>fs/fat: avoid noisy message fat_read_file()</title>
<updated>2023-01-20T15:38:52+00:00</updated>
<author>
<name>Heinrich Schuchardt</name>
<email>heinrich.schuchardt@canonical.com</email>
</author>
<published>2023-01-19T14:37:40+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=de9433550b01547c3207de9f7060092242c91569'/>
<id>de9433550b01547c3207de9f7060092242c91569</id>
<content type='text'>
UEFI applications call file system functions to determine if a file exists.
The return codes are evaluated to show appropriate messages.
U-Boot's file system layer should not interfere with the output.

Rename file_fat_read_at() to fat_read_file() adjusting the parameter
sequence and names and eliminate the old wrapper function.

Signed-off-by: Heinrich Schuchardt &lt;heinrich.schuchardt@canonical.com&gt;
Reviewed-by: Tom Rini &lt;trini@konsulko.com&gt;
Reviewed-by: Ilias Apalodimas &lt;ilias.apalodimas@linaro.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
UEFI applications call file system functions to determine if a file exists.
The return codes are evaluated to show appropriate messages.
U-Boot's file system layer should not interfere with the output.

Rename file_fat_read_at() to fat_read_file() adjusting the parameter
sequence and names and eliminate the old wrapper function.

Signed-off-by: Heinrich Schuchardt &lt;heinrich.schuchardt@canonical.com&gt;
Reviewed-by: Tom Rini &lt;trini@konsulko.com&gt;
Reviewed-by: Ilias Apalodimas &lt;ilias.apalodimas@linaro.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>lib: zstd: update to latest Linux zstd 1.5.2</title>
<updated>2023-01-19T00:04:17+00:00</updated>
<author>
<name>Brandon Maier</name>
<email>brandon.maier@collins.com</email>
</author>
<published>2023-01-12T16:27:45+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=4b9b25d943ff95c7421cab261333fc29852fe3b1'/>
<id>4b9b25d943ff95c7421cab261333fc29852fe3b1</id>
<content type='text'>
Update the zstd implementation to match Linux zstd 1.5.2 from commit
2aa14b1ab2.

This was motivated by running into decompression corruption issues when
trying to uncompress files compressed with newer versions of zstd. zstd
users also claim significantly improved decompression times with newer
zstd versions which is a side benefit.

Original zstd code was copied from Linux commit 2aa14b1ab2 which is a
custom-built implementation based on zstd 1.3.1. Linux switched to an
implementation that is a copy of the upstream zstd code in Linux commit
e0c1b49f5b, this results in a large code diff. However this should make
future updates easier along with other benefits[1].

This commit is a straight mirror of the Linux zstd code, except to:
- update a few #include that do not translate cleanly
  - linux/swab.h -&gt; asm/byteorder.h
  - linux/limits.h -&gt; linux/kernel.h
  - linux/module.h -&gt; linux/compat.h
- remove assert() from debug.h so it doesn't conflict with u-boot's
  assert()
- strip out the compressor code as was done in the previous u-boot zstd
- update existing zstd users to the new Linux zstd API
- change the #define for MEM_STATIC to use INLINE_KEYWORD for codesize
- add a new KConfig option that sets zstd build options to minify code
  based on zstd's ZSTD_LIB_MINIFY[2].

These changes were tested by booting a zstd 1.5.2 compressed kernel inside a
FIT. And the squashfs changes by loading a file from zstd compressed squashfs
with sqfsload. buildman was used to compile test other boards and check for
binary bloat, as follows:

&gt; $ buildman -b zstd2 --boards dh_imx6,m53menlo,mvebu_espressobin-88f3720,sandbox,sandbox64,stm32mp15_dhcom_basic,stm32mp15_dhcor_basic,turris_mox,turris_omnia -sS
&gt; Summary of 6 commits for 9 boards (8 threads, 1 job per thread)
&gt; 01: Merge branch '2023-01-10-platform-updates'
&gt;        arm:  w+   m53menlo dh_imx6
&gt; 02: lib: zstd: update to latest Linux zstd 1.5.2
&gt;    aarch64: (for 2/2 boards) all -3186.0 rodata +920.0 text -4106.0
&gt;        arm: (for 5/5 boards) all +1254.4 rodata +940.0 text +314.4
&gt;    sandbox: (for 2/2 boards) all -4452.0 data -16.0 rodata +640.0 text -5076.0

[1] https://github.com/torvalds/linux/commit/e0c1b49f5b674cca7b10549c53b3791d0bbc90a8
[2] https://github.com/facebook/zstd/blob/f302ad8811643c428c4e3498e28f53a0578020d3/lib/libzstd.mk#L31

Signed-off-by: Brandon Maier &lt;brandon.maier@collins.com&gt;
[trini: Set ret to -EINVAL for the error of "failed to detect
compressed" to fix warning, drop ZSTD_SRCSIZEHINT_MAX for non-Linux host
tool builds]
Signed-off-by: Tom Rini &lt;trini@konsulko.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Update the zstd implementation to match Linux zstd 1.5.2 from commit
2aa14b1ab2.

This was motivated by running into decompression corruption issues when
trying to uncompress files compressed with newer versions of zstd. zstd
users also claim significantly improved decompression times with newer
zstd versions which is a side benefit.

Original zstd code was copied from Linux commit 2aa14b1ab2 which is a
custom-built implementation based on zstd 1.3.1. Linux switched to an
implementation that is a copy of the upstream zstd code in Linux commit
e0c1b49f5b, this results in a large code diff. However this should make
future updates easier along with other benefits[1].

This commit is a straight mirror of the Linux zstd code, except to:
- update a few #include that do not translate cleanly
  - linux/swab.h -&gt; asm/byteorder.h
  - linux/limits.h -&gt; linux/kernel.h
  - linux/module.h -&gt; linux/compat.h
- remove assert() from debug.h so it doesn't conflict with u-boot's
  assert()
- strip out the compressor code as was done in the previous u-boot zstd
- update existing zstd users to the new Linux zstd API
- change the #define for MEM_STATIC to use INLINE_KEYWORD for codesize
- add a new KConfig option that sets zstd build options to minify code
  based on zstd's ZSTD_LIB_MINIFY[2].

These changes were tested by booting a zstd 1.5.2 compressed kernel inside a
FIT. And the squashfs changes by loading a file from zstd compressed squashfs
with sqfsload. buildman was used to compile test other boards and check for
binary bloat, as follows:

&gt; $ buildman -b zstd2 --boards dh_imx6,m53menlo,mvebu_espressobin-88f3720,sandbox,sandbox64,stm32mp15_dhcom_basic,stm32mp15_dhcor_basic,turris_mox,turris_omnia -sS
&gt; Summary of 6 commits for 9 boards (8 threads, 1 job per thread)
&gt; 01: Merge branch '2023-01-10-platform-updates'
&gt;        arm:  w+   m53menlo dh_imx6
&gt; 02: lib: zstd: update to latest Linux zstd 1.5.2
&gt;    aarch64: (for 2/2 boards) all -3186.0 rodata +920.0 text -4106.0
&gt;        arm: (for 5/5 boards) all +1254.4 rodata +940.0 text +314.4
&gt;    sandbox: (for 2/2 boards) all -4452.0 data -16.0 rodata +640.0 text -5076.0

[1] https://github.com/torvalds/linux/commit/e0c1b49f5b674cca7b10549c53b3791d0bbc90a8
[2] https://github.com/facebook/zstd/blob/f302ad8811643c428c4e3498e28f53a0578020d3/lib/libzstd.mk#L31

Signed-off-by: Brandon Maier &lt;brandon.maier@collins.com&gt;
[trini: Set ret to -EINVAL for the error of "failed to detect
compressed" to fix warning, drop ZSTD_SRCSIZEHINT_MAX for non-Linux host
tool builds]
Signed-off-by: Tom Rini &lt;trini@konsulko.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>fs/btrfs: handle data extents, which crosss stripe boundaries, correctly</title>
<updated>2023-01-11T20:02:24+00:00</updated>
<author>
<name>Qu Wenruo</name>
<email>wqu@suse.com</email>
</author>
<published>2022-12-30T01:07:05+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=11d567012558fab7da9d1189948cb6005c081ccd'/>
<id>11d567012558fab7da9d1189948cb6005c081ccd</id>
<content type='text'>
[BUG]
Since btrfs supports single device RAID0 at mkfs time after btrfs-progs
v5.14, if we create a single device raid0 btrfs, and created a file
crossing stripe boundary:

  # mkfs.btrfs -m dup -d raid0 test.img
  # mount test.img mnt
  # xfs_io -f -c "pwrite 0 128K" mnt/file
  # umount mnt

Since btrfs is using 64K as stripe length, above 128K data write is
definitely going to cross at least one stripe boundary.

Then u-boot would fail to read above 128K file:

 =&gt; host bind 0 /home/adam/test.img
 =&gt; ls host 0
 &lt;   &gt;     131072  Fri Dec 30 00:18:25 2022  file
 =&gt; load host 0 0 file
 BTRFS: An error occurred while reading file file
 Failed to load 'file'

[CAUSE]
Unlike tree blocks read, data extent reads doesn't consider cases in which
one data extent can cross stripe boundary.

In read_data_extent(), we just call btrfs_map_block() once and read the
first mapped range.

And if the first mapped range is smaller than the desired range, it
would return error.

But since even single device btrfs can utilize RAID0 profiles, the first
mapped range can only be at most 64K for RAID0 profiles, and cause false
error.

[FIX]
Just like read_whole_eb(), we should call btrfs_map_block() in a loop
until we read all data.

Since we're here, also add extra error messages for the following cases:

- btrfs_map_block() failure
  We already have the error message for it.

- Missing device
  This should not happen, as we only support single device for now.

- __btrfs_devread() failure

With this bug fixed, btrfs driver of u-boot can properly read the above
128K file, and have the correct content:

 =&gt; host bind 0 /home/adam/test.img
 =&gt; ls host 0
 &lt;   &gt;     131072  Fri Dec 30 00:18:25 2022  file
 =&gt; load host 0 0 file
 131072 bytes read in 0 ms
 =&gt; md5sum 0 0x20000
 md5 for 00000000 ... 0001ffff ==&gt; d48858312a922db7eb86377f638dbc9f
 ^^^ Above md5sum also matches.

Reported-by: Sam Winchenbach &lt;swichenbach@tethers.com&gt;
Signed-off-by: Qu Wenruo &lt;wqu@suse.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[BUG]
Since btrfs supports single device RAID0 at mkfs time after btrfs-progs
v5.14, if we create a single device raid0 btrfs, and created a file
crossing stripe boundary:

  # mkfs.btrfs -m dup -d raid0 test.img
  # mount test.img mnt
  # xfs_io -f -c "pwrite 0 128K" mnt/file
  # umount mnt

Since btrfs is using 64K as stripe length, above 128K data write is
definitely going to cross at least one stripe boundary.

Then u-boot would fail to read above 128K file:

 =&gt; host bind 0 /home/adam/test.img
 =&gt; ls host 0
 &lt;   &gt;     131072  Fri Dec 30 00:18:25 2022  file
 =&gt; load host 0 0 file
 BTRFS: An error occurred while reading file file
 Failed to load 'file'

[CAUSE]
Unlike tree blocks read, data extent reads doesn't consider cases in which
one data extent can cross stripe boundary.

In read_data_extent(), we just call btrfs_map_block() once and read the
first mapped range.

And if the first mapped range is smaller than the desired range, it
would return error.

But since even single device btrfs can utilize RAID0 profiles, the first
mapped range can only be at most 64K for RAID0 profiles, and cause false
error.

[FIX]
Just like read_whole_eb(), we should call btrfs_map_block() in a loop
until we read all data.

Since we're here, also add extra error messages for the following cases:

- btrfs_map_block() failure
  We already have the error message for it.

- Missing device
  This should not happen, as we only support single device for now.

- __btrfs_devread() failure

With this bug fixed, btrfs driver of u-boot can properly read the above
128K file, and have the correct content:

 =&gt; host bind 0 /home/adam/test.img
 =&gt; ls host 0
 &lt;   &gt;     131072  Fri Dec 30 00:18:25 2022  file
 =&gt; load host 0 0 file
 131072 bytes read in 0 ms
 =&gt; md5sum 0 0x20000
 md5 for 00000000 ... 0001ffff ==&gt; d48858312a922db7eb86377f638dbc9f
 ^^^ Above md5sum also matches.

Reported-by: Sam Winchenbach &lt;swichenbach@tethers.com&gt;
Signed-off-by: Qu Wenruo &lt;wqu@suse.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>fs/squashfs: Only use export table if available</title>
<updated>2023-01-11T20:02:24+00:00</updated>
<author>
<name>David Oberhollenzer</name>
<email>goliath@infraroot.at</email>
</author>
<published>2022-12-25T10:05:24+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=bf48dde80a6c302b3279fe8ed1e5eb9e8fef4abd'/>
<id>bf48dde80a6c302b3279fe8ed1e5eb9e8fef4abd</id>
<content type='text'>
For a squashfs filesystem, the fragment table is followed by
the following tables: NFS export table, ID table, xattr table.

The export and xattr tables are both completely optional, but
the ID table is mandatory. The Linux implementation refuses to
mount the image if the ID table is missing. Tables that are no
present have their location in the super block set
to 0xFFFFFFFFFFFFFFFF.

The u-boot implementation previously assumed that it can always
rely on the export table location as an upper bound for the fragment
table, trying (and failing) to read past filesystem bounds if it
is not present.

This patch changes the driver to use the ID table instead and only
use the export table location if it lies between the two.

Signed-off-by: David Oberhollenzer &lt;goliath@infraroot.at&gt;
Reviewed-by: Miquel Raynal &lt;miquel.raynal@bootlin.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
For a squashfs filesystem, the fragment table is followed by
the following tables: NFS export table, ID table, xattr table.

The export and xattr tables are both completely optional, but
the ID table is mandatory. The Linux implementation refuses to
mount the image if the ID table is missing. Tables that are no
present have their location in the super block set
to 0xFFFFFFFFFFFFFFFF.

The u-boot implementation previously assumed that it can always
rely on the export table location as an upper bound for the fragment
table, trying (and failing) to read past filesystem bounds if it
is not present.

This patch changes the driver to use the ID table instead and only
use the export table location if it lies between the two.

Signed-off-by: David Oberhollenzer &lt;goliath@infraroot.at&gt;
Reviewed-by: Miquel Raynal &lt;miquel.raynal@bootlin.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>fs/squashfs: use lldiv function for math</title>
<updated>2022-12-08T14:29:02+00:00</updated>
<author>
<name>Kasper Revsbech</name>
<email>kasper.revsbech.ext@siemensgamesa.com</email>
</author>
<published>2022-12-01T15:30:32+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=aeea67f9a033ab6f3adca7b30bbd02579f72512f'/>
<id>aeea67f9a033ab6f3adca7b30bbd02579f72512f</id>
<content type='text'>
When compling for x86:
u-boot/fs/squashfs/sqfs.c:90: undefined reference to `__udivmoddi4'

Signed-off-by: Kasper Revsbech &lt;kasper.revsbech.ext@siemensgamesa.com&gt;
Tested-by: Sean Nyekjaer &lt;sean@geanix.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When compling for x86:
u-boot/fs/squashfs/sqfs.c:90: undefined reference to `__udivmoddi4'

Signed-off-by: Kasper Revsbech &lt;kasper.revsbech.ext@siemensgamesa.com&gt;
Tested-by: Sean Nyekjaer &lt;sean@geanix.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>fs: ext4: Fix free(NULL)</title>
<updated>2022-12-08T14:28:31+00:00</updated>
<author>
<name>Mikhail Ilin</name>
<email>ilin.mikhail.ol@gmail.com</email>
</author>
<published>2022-11-22T08:00:55+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=04e6332ec0b139a0b7452551455ae96428c7d1ef'/>
<id>04e6332ec0b139a0b7452551455ae96428c7d1ef</id>
<content type='text'>
The 'depth_dirname', 'ptr', 'parent_inode' and 'first_inode' pointers
may be null. Thus, it is necessary to check them before using free() to
avoid free(NULL) cases.

Fixes: 934b14f2bb30 ("ext4: free allocations by parse_path()")
Signed-off-by: Mikhail Ilin &lt;ilin.mikhail.ol@gmail.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The 'depth_dirname', 'ptr', 'parent_inode' and 'first_inode' pointers
may be null. Thus, it is necessary to check them before using free() to
avoid free(NULL) cases.

Fixes: 934b14f2bb30 ("ext4: free allocations by parse_path()")
Signed-off-by: Mikhail Ilin &lt;ilin.mikhail.ol@gmail.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
