| Age | Commit message (Collapse) | Author |
|---|
|
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 <p.raghav@samsung.com>
Reviewed-by: Qu Wenruo <wqu@suse.com>
|
|
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 <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Huang Jianan <jnhuang95@gmail.com>
|
|
Move this out of the common header and include it only where needed.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
A large number of files include <flash.h> as it used to be how various
SPI flash related functions were found, or for other reasons entirely.
In order to migrate some further CONFIG symbols to Kconfig we need to
not include flash.h in cases where we don't have a NOR flash of some
sort enabled. Furthermore, in cases where we are in common code and it
doesn't make sense to try and further refactor the code itself in to new
files we need to guard this inclusion.
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
Fix diacritics in some instances of my name and change my e-mail address
to kabel@kernel.org.
Add corresponding .mailmap entries.
Signed-off-by: Marek Behún <kabel@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
|
|
U-Boot already provides assert function, so it use also in ubi and ubifs code.
Signed-off-by: Pali Rohár <pali@kernel.org>
|
|
U-Boot does not implement down_write_trylock() and its stub always returns
true that lock was acquired. Therefore ubifs_assert_cmt_locked() assert
currently always fails.
Fix this issue by redefining ubifs_assert_cmt_locked() to just empty stub
as there is nothing to assert.
Signed-off-by: Pali Rohár <pali@kernel.org>
|
|
|
|
Original ubifs code was designed that after ubifs_umount() call it is
required to also call ubi_close_volume() which closes underlying UBI
volume. But U-Boot ubifs modification have not implemented it properly
which caused that ubifsumount command contains resource leak. It can be
observed by calling simple sequence of commands:
=> ubi part mtd2
ubi0: attaching mtd2
...
=> ubifsmount ubi0
=> ubifsumount
Unmounting UBIFS volume rootfs!
=> ubi detach
ubi0 error: ubi_detach_mtd_dev: ubi0 reference count 1, destroy anyway
ubi0: detaching mtd2
ubi0: mtd2 is detached
Fix this issue by calling ubi_close_volume() and mutex_unlock() in
directly in ubifs_umount() function before freeing U-Boot's global
ubifs_sb. And remove duplicate calls of these two functions in remaining
places. Note that when ubifs_umount() is not called then during error
handling is still needed to call ubi_close_volume() and mutex_unlock.
With this change ubifsumount command does not throw that error anymore:
=> ubi part rootfs
ubi0: attaching mtd2
...
=> ubifsmount ubi0
=> ubifsumount
Unmounting UBIFS volume rootfs!
=> ubi detach
ubi0: detaching mtd2
ubi0: mtd2 is detached
Signed-off-by: Pali Rohár <pali@kernel.org>
|
|
Tighten up symbol dependencies in a number of places. Ensure that a SPL
specific option has at least a direct dependency on SPL. In places
where it's clear that we depend on something more specific, use that
dependency instead. This means in a very small number of places we can
drop redundant dependencies.
Reported-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
A crafted squashfs image could embed a huge number of empty metadata
blocks in order to make the amount of malloc()'d memory overflow and be
much smaller than expected. Because of this flaw, any random code
positioned at the right location in the squashfs image could be memcpy'd
from the squashfs structures into U-Boot code location while trying to
access the rearmost blocks, before being executed.
In order to prevent this vulnerability from being exploited in eg. a
secure boot environment, let's add a check over the amount of data
that is going to be allocated. Such a check could look like:
if (!elem_size || n > SIZE_MAX / elem_size)
return NULL;
The right way to do it would be to enhance the calloc() implementation
but this is quite an impacting change for such a small fix. Another
solution would be to add the check before the malloc call in the
squashfs implementation, but this does not look right. So for now, let's
use the kcalloc() compatibility function from Linux, which has this
check.
Fixes: c5100613037 ("fs/squashfs: new filesystem")
Reported-by: Tatsuhiko Yasumatsu <Tatsuhiko.Yasumatsu@sony.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Tested-by: Tatsuhiko Yasumatsu <Tatsuhiko.Yasumatsu@sony.com>
|
|
Merge in v2022.07-rc5.
|
|
Following Jincheng's report, an out-of-band write leading to arbitrary
code execution is possible because on one side the squashfs logic
accepts directory names up to 65535 bytes (u16), while U-Boot fs logic
accepts directory names up to 255 bytes long.
Prevent such an exploit from happening by capping directory name sizes
to 255. Use a define for this purpose so that developers can link the
limitation to its source and eventually kill it some day by dynamically
allocating this array (if ever desired).
Link: https://lore.kernel.org/all/CALO=DHFB+yBoXxVr5KcsK0iFdg+e7ywko4-e+72kjbcS8JBfPw@mail.gmail.com
Reported-by: Jincheng Wang <jc.w4ng@gmail.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Tested-by: Jincheng Wang <jc.w4ng@gmail.com>
|
|
Setting sblk = NULL has no effect on the caller.
We want to set *sblk = NULL if an error occurrs to avoid usage after free.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
|
|
After returning if ret <= 0 we know that ret > 0. No need to check it.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Anand Jain <anand.jain>
|
|
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
|
Commit b1a14f8a1c2e ("UBIFS: Change ubifsload to not read beyond the
requested size") added optimization to do not read more bytes than it is
really needed. But this commit introduced incorrect handling of the hole at
the end of file. This logic cause U-Boot to crash or lockup when trying to
read from the ubifs filesystem.
When read_block() call returns -ENOENT error (not an error, but the hole)
then dn-> structure is not filled and contain garbage. So using of dn->size
for memcpy() argument cause that U-Boot tries to copy unspecified amount of
bytes from possible unmapped memory. Which randomly cause lockup of P2020
CPU.
Fix this issue by copying UBIFS_BLOCK_SIZE bytes from read buffer when
dn->size is not available. UBIFS_BLOCK_SIZE is the size of the buffer
itself and read_block() fills buffer by zeros when it returns -ENOENT.
This patch fixes ubifsload on P2020.
Fixes: b1a14f8a1c2e ("UBIFS: Change ubifsload to not read beyond the requested size")
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
|
|
When compling for x86:
ld.bfd: fs/squashfs/sqfs.o: in function `sqfs_read':
u-boot/fs/squashfs/sqfs.c:1443: undefined reference to `__udivmoddi4'
ld.bfd: u-boot/fs/squashfs/sqfs.c:1521: undefined reference to `__udivmoddi4'
Signed-off-by: Sean Nyekjaer <sean.nyekjaer.ext@siemensgamesa.com>
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Pali Rohár <pali@kernel.org>
|
|
It is helpful to be able to try out bootstd on sandbox, using host files.
This is easier than using a block device, which must have a filesystem,
partition table, etc.
Add a new driver which provides this feature. For now it is not used in
tests, but it is likely to be useful.
Add notes in the devicetree also, but don't disturb the tests.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
When sandbox is used with hostfs we won't have a block device, but still
must set up the filesystem type before any filesystem operation, such as
loading a file. Add a function to handle this.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Implementation in linux/crc16.h provides standard CRC-16 algorithm with
polynomial x^16 + x^15 + x^2 + 1. Use it and remove duplicate ext4 CRC-16
specific code.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
|
|
This implementation provides standard CRC-16 algorithm with polynomial
x^16 + x^15 + x^2 + 1.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
|
|
File fs/ubifs/crc16.h is standard linux's crc16.h include file. So move it
from fs/ubifs to include/linux where are also other linux include files.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
|
|
CONFIG_SPL_FS_SQUASHFS cannot be disabled when CONFIG_FS_SQUASHFS is
enabled. Fix it.
Signed-off-by: Pali Rohár <pali@kernel.org>
|
|
Currently there is no btrfs support in SPL. But macro CONFIG_FS_BTRFS is
defined also when building SPL. When both FS_BTRFS and SPL are enabled
then build process throw compile error.
Fix check for btrfs code in fstypes[] to allow compiling FS_BTRFS only in
proper U-Boot.
Signed-off-by: Pali Rohár <pali@kernel.org>
|
|
Fix following two compile errors on big endian systems:
CC fs/btrfs/btrfs.o
In file included from include/linux/byteorder/big_endian.h:107,
from ./arch/powerpc/include/asm/byteorder.h:82,
from ./arch/powerpc/include/asm/bitops.h:8,
from include/linux/bitops.h:152,
from include/uuid.h:9,
from fs/btrfs/btrfs.c:10:
fs/btrfs/conv-funcs.h: In function ‘btrfs_key_to_disk’:
include/linux/byteorder/generic.h:90:21: error: ‘__cpu_to_le16’ undeclared (first use in this function); did you mean ‘__cpu_to_le16p’?
#define cpu_to_le16 __cpu_to_le16
^~~~~~~~~~~~~
fs/btrfs/conv-funcs.h:79:10: note: in expansion of macro ‘cpu_to_le16’
__u16: cpu_to_le16, \
^~~~~~~~~~~
CC fs/btrfs/compression.o
In file included from ./arch/powerpc/include/asm/unaligned.h:9,
from fs/btrfs/compression.c:16:
include/linux/unaligned/access_ok.h:6:19: error: redefinition of ‘get_unaligned_le16’
static inline u16 get_unaligned_le16(const void *p)
^~~~~~~~~~~~~~~~~~
In file included from fs/btrfs/ctree.h:16,
from fs/btrfs/btrfs.h:12,
from fs/btrfs/compression.c:8:
include/linux/unaligned/le_byteshift.h:40:19: note: previous definition of ‘get_unaligned_le16’ was here
static inline u16 get_unaligned_le16(const void *p)
^~~~~~~~~~~~~~~~~~
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 <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Qu Wenruo <wqu@suse.com>
|
|
* Don't check argument of free(). Free does this itself.
* Reduce scope of data_buffer. Remove duplicate free().
* Avoid superfluous NULL assignment.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
|
Currently there is no UBIFS support in SPL. But macro CONFIG_CMD_UBIFS is
defined also when building SPL. when both CMD_UBIFS and SPL are enabled
then build process throw compile error.
Fix check for ubifs code in fstypes[] to allow compiling CMD_UBIFS only in
proper U-Boot.
Signed-off-by: Pali Rohár <pali@kernel.org>
|
|
CONFIG_SPL_FS_FAT cannot be disabled when CONFIG_FS_FAT is enabled. Fix it.
Signed-off-by: Pali Rohár <pali@kernel.org>
|
|
Backport commit 1cb51a15b576 ("ubifs: Fix journal replay wrt. xattr
nodes") from the Linux Kernel, which has the following Signed-off-by
line:
Signed-off-by: Richard Weinberger <richard@nod.at>
For U-Boot, after comapring with the upstream commit:
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
This adds a filesystem which is backed by the host's filesystem. It is
modeled off of sandboxfs, which has very similar aims. Semihosting
doesn't support listing directories (except with SYS_SYSTEM), so neither
do we. it's possible to optimize a bit for the common case of reading a
whole file by omitting a call to smh_seek, but this is left as a future
optimization.
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
|
|
Support EROFS lz4 compressed files.
Signed-off-by: Huang Jianan <jnhuang95@gmail.com>
|
|
This patch mainly deals with uncompressed files.
Signed-off-by: Huang Jianan <jnhuang95@gmail.com>
|
|
Signed-off-by: Lars Weber <weber@weber-software.com>
|
|
Sphinx expects Return: and not @return to indicate a return value.
find . -name '*.c' -exec \
sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \;
find . -name '*.h' -exec \
sed -i 's/^\(\s\)\*\(\s*\)@return\(\s\)/\1*\2Return:\3/' {} \;
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
|
|
NO_HOLE feature correctly
[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
# xfs_io -f -c "pwrite 0 4k" -c "pwrite 8k 4k" /mnt/btrfs/file
# md5sum /mnt/btrfs/file
277f3840b275c74d01e979ea9d75ac19 /mnt/btrfs/file
# umount /mnt/btrfs
# ./u-boot
=> host bind 0 /home/adam/test.img
=> ls host 0
< > 12288 Mon Dec 27 05:35:23 2021 file
=> load host 0 0x1000000 file
12288 bytes read in 0 ms
=> md5sum 0x1000000 0x3000
md5 for 01000000 ... 01002fff ==> 855ffdbe4d0ccc5acab92e1b5330e4c1
The md5sum doesn't match at all.
[CAUSE]
In U-boot btrfs implementation, the function btrfs_read_file() has the
following iteration for file extent iteration:
/* Read the aligned part */
while (cur < aligned_end) {
ret = lookup_data_extent(root, &path, ino, cur, &next_offset);
if (ret < 0)
goto out;
if (ret > 0) {
/* No next, direct exit */
if (!next_offset) {
ret = 0;
goto out;
}
}
/* Read file extent */
But for NO_HOLES features, hole extents will not have any extent item
for it.
Thus if @cur is at a hole, lookup_data_extent() will just return >0, and
update @next_offset.
But we still believe there is some data to read for @cur for ret > 0
case, causing we read extent data from the next file extent.
This means, what we do for above NO_HOLES btrfs is:
- Read 4K data from disk to file offset [0, 4K)
So 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_extent().
Signed-off-by: Qu Wenruo <wqu@suse.com>
|
|
Now btrfs can utilize the newly intorudced BLAKE2 hash.
Signed-off-by: Qu Wenruo <wqu@suse.com>
|
|
This converts the following to Kconfig:
CONFIG_JFFS2_DEV
CONFIG_JFFS2_LZO
CONFIG_JFFS2_NAND
CONFIG_JFFS2_PART_OFFSET
CONFIG_JFFS2_PART_SIZE
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
For the symbols which are both hard-coded as enabled and used, move to
Kconfig. The rest of the CONFIG_YAFFS namespace is unselected anywhere,
so we leave it as is.
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
- Fix mtd erase with mtdpart (Marek Behún)
- NXP fspi driver fixes (Kuldeep Singh)
|
|
The original purpose of mtd_erase_callback() in Linux at the time it was
imported to U-Boot, was to inform the caller that erasing is done (since
it was an asynchronous operation).
All supplied callback methods in U-Boot do nothing, but the
mtd_erase_callback() function was (until previous patch) grossly abused
in U-Boot's mtdpart implementation for completely different purpose.
Since we got rid of the abusement, remove the mtd_erase_callback()
function and the .callback member from struct erase_info entirely, in
order to avoid such problems in the future.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
|
|
This patch optimizes the commit mentioned below by avoiding running
a set of commands which are useless in the case when
size < mydata->sect_size and sect_count would be 0.
Fixes: 5b3ddb17ba ("fs/fat/fat.c: Do not perform zero block reads if there are no blocks left")
Signed-off-by: Ricardo Salveti <ricardo@foundries.io>
Co-developed-by: Oleksandr Suvorov <oleksandr.suvorov@foundries.io>
Signed-off-by: Oleksandr Suvorov <oleksandr.suvorov@foundries.io>
|
|
Use the common function to avoid code duplication.
Acked-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
We only include <linux/mtd/rawnand.h> in <nand.h> for the forward
declaration of struct nand_chip, so do that directly. Then, include
<linux/mtd/rawnand.h> where required directly.
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
Signed-off-by: Wolfgang Denk <wd@denx.de>
|
|
Signed-off-by: Wolfgang Denk <wd@denx.de>
|
|
Prepare v2021.10-rc5
|
|
Output like the following is quite irritating:
=> bootefi hello
Scanning disk mmc2.blk...
No valid Btrfs found
Bad magic number for SquashFS image.
** Unrecognized filesystem type **
Scanning disk mmc1.blk...
No valid Btrfs found
Bad magic number for SquashFS image.
** Unrecognized filesystem type **
Scanning disk mmc0.blk...
No valid Btrfs found
Bad magic number for SquashFS image.
** Unrecognized filesystem type **
Albeit a whole disk may be formatted with a filesystem in most cases
a partition table is used and the whole disk (partition number 0) doesn't
contain a filesytem. Some partitions may only contain a blob. Not seeing a
filesytem on the whole disk or on any partition is only worth a debug
message.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
This message comes up a lot when scanning filesystems. It suggests to the
user that there is some sort of error, but in fact there is no reason to
expect that a particular partition has a sqfs filesystem. Other
filesystems don't print this error.
Turn it into a debug message.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
|
This message comes up a lot when scanning filesystems. It suggests to the
user that there is some sort of error, but in fact there is no reason to
expect that a particular partition has a btrfs filesystem. Other
filesystems don't print this error.
Turn it into a debug message.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Qu Wenruo <wqu@suse.com>
|
