The block count entry in the EXT4 filesystem disk structures uses
standard 512-bytes units for most of the typical files. The only
exception are HUGE files, which use the filesystem block size, but those
are not supported by uboot's EXT4 implementation anyway. This patch fixes
the EXT4 code to use proper unit count for inode block count. This fixes
errors reported by fsck.ext4 on disks with non-standard (i.e. 4KiB, in
case of new flash drives) PHYSICAL block size after using 'ext4write'
uboot's command.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Re-use the functions used to write/create a file, to support creation of a
symbolic link.
The difference with a regular file are small:
- The inode mode is flagged with S_IFLNK instead of S_IFREG
- The ext2_dirent's filetype is FILETYPE_SYMLINK instead of FILETYPE_REG
- Instead of storing the content of a file in allocated blocks, the path
to the target is stored. And if the target's path is short enough, no block
is allocated and the target's path is stored in ext2_inode.b.symlink
As with regulars files, if a file/symlink with the same name exits, it is
unlinked first and then re-created.
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
[trini: Fix ext4 env code]
Signed-off-by: Tom Rini <trini@konsulko.com>
There is no need to modify the buffer passed to ext4fs_write_file().
The memset() call is not required here and was likely copied from the
equivalent part of the ext4fs_read_file() function where we do need it.
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
When a file contains extents, U-Boot currently reads extent-related data
for each block in the file, even if that data is located in the same
block each time. This significantly slows down loading of files that use
extents. Implement a very dumb cache to prevent repeatedly reading the
same block. Files with extents now load as fast as files without.
Note: There are many cases where read_allocated_block() is called. This
patch only addresses one of those places; all others still read redundant
data in any case they did before. This is a minimal patch to fix the
load command; other cases aren't fixed.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
U-Boot doesn't support metadata_csum feature. Writing to filesystem with
metadata_csum feature makes the filesystem corrupted and unbootable by
Linux:
[ 2.527495] EXT4-fs (mmcblk0p2): ext4_check_descriptors: Checksum for group 0 failed (52188!=0)
[ 2.537421] EXT4-fs (mmcblk0p2): ext4_check_descriptors: Checksum for group 1 failed (5262!=0)
...
[ 2.653308] EXT4-fs (mmcblk0p2): ext4_check_descriptors: Checksum for group 14 failed (42611!=0)
[ 2.662179] EXT4-fs (mmcblk0p2): ext4_check_descriptors: Checksum for group 15 failed (21527!=0)
[ 2.687920] JBD2: journal checksum error
[ 2.691982] EXT4-fs (mmcblk0p2): error loading journal
[ 2.698292] VFS: Cannot open root device "mmcblk0p2" or unknown-block(179,2): error -74
Don't write to filesystem with meatadata_csum feature to not corrupt the
filesystem.
Signed-off-by: Sébastien Szymanski <sebastien.szymanski@armadeus.com>
When U-Boot started using SPDX tags we were among the early adopters and
there weren't a lot of other examples to borrow from. So we picked the
area of the file that usually had a full license text and replaced it
with an appropriate SPDX-License-Identifier: entry. Since then, the
Linux Kernel has adopted SPDX tags and they place it as the very first
line in a file (except where shebangs are used, then it's second line)
and with slightly different comment styles than us.
In part due to community overlap, in part due to better tag visibility
and in part for other minor reasons, switch over to that style.
This commit changes all instances where we have a single declared
license in the tag as both the before and after are identical in tag
contents. There's also a few places where I found we did not have a tag
and have introduced one.
Signed-off-by: Tom Rini <trini@konsulko.com>
The descriptor size is variable, thus array indices are not generically
applicable. The larger group descriptors also contain e.g. high parts
of block numbers, which have to be read and written.
Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
read_allocated block may return block number 0, which is just an indicator
a chunk of the file is not backed by a block, i.e. it is sparse.
During file deletions, just continue with the next logical block, for other
operations treat blocknumber <= 0 as an error.
For writes, blocknumber 0 should never happen, as U-Boot always allocates
blocks for the whole file. Reading already handles this correctly, i.e. the
read buffer is 0-fillled.
Not treating block 0 as sparse block leads to FS corruption, e.g.
./sandbox/u-boot -c 'host bind 0 ./sandbox/test/fs/3GB.ext4.img ;
ext4write host 0 0 /2.5GB.file 1 '
The 2.5GB.file from the fs test is actually a sparse file.
Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
The data blocks are identical for files using traditional direct/indirect
block allocation scheme and extent trees, thus this code part can be
common. Only the code to deallocate the indirect blocks to record the
used blocks has to be seperate, respectively the code to release extent
tree index blocks.
Actually the code to release the extent tree index blocks is still missing,
but at least add a FIXME at the appropriate place.
Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
Make sure the the extra_isize field (offset 128) is initialized to 0, to
mark any extra data as invalid.
Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
Reviewed-by: Lukasz Majewski <l.majewski@samsung.com>
fs->inodesz is already correctly (i.e. dependent on fs revision)
initialized in ext4fs_mount.
Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
Reviewed-by: Lukasz Majewski <l.majewski@samsung.com>
temp_ptr should always be freed, even if the function is left via
goto fail.
Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
Reviewed-by: Lukasz Majewski <l.majewski@samsung.com>
While directories can be read using the old linear scan method, adding a
new file would require updating the index tree (alternatively, the whole
tree could be removed).
Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
Reviewed-by: Lukasz Majewski <l.majewski@samsung.com>
In case the dir entry creation failed, ext4fs_write would later overwrite
a random inode, as inodeno was never initialized.
Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
Reviewed-by: Lukasz Majewski <l.majewski@samsung.com>
The following command triggers a segfault in search_dir:
./sandbox/u-boot -c 'host bind 0 ./sandbox/test/fs/3GB.ext4.img ;
ext4write host 0 0 /./foo 0x10'
The following command triggers a segfault in check_filename:
./sandbox/u-boot -c 'host bind 0 ./sandbox/test/fs/3GB.ext4.img ;
ext4write host 0 0 /. 0x10'
"." is the first entry in the directory, thus previous_dir is NULL. The
whole previous_dir block in search_dir seems to be a bad copy from
check_filename(...). As the changed data is not written to disk, the
statement is mostly harmless, save the possible NULL-ptr reference.
Typically a file is unlinked by extending the direntlen of the previous
entry. If the entry is the first entry in the directory block, it is
invalidated by setting inode=0.
The inode==0 case is hard to trigger without crafted filesystems. It only
hits if the first entry in a directory block is deleted and later a lookup
for the entry (by name) is done.
Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
Reviewed-by: Lukasz Majewski <l.majewski@samsung.com>
All fields were accessed directly instead of using the proper byte swap
functions. Thus, ext4 write support was only usable on little-endian
architectures. Fix this.
Signed-off-by: Michael Walle <michael@walle.cc>
ext4_write_file() is only called from the "fs" layer, which calls both
ext4fs_mount() and ext4fs_close() before/after calling ext4_write_file().
Fix ext4_write_file() not to call ext4fs_mount() again, since the mount
operation malloc()s some RAM which is leaked when a second mount call
over-writes the pointer to that data, if no intervening close call is
made.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Lukasz Majewski <l.majewski@samsung.com>
Tested-by: Lukasz Majewski <l.majewski@samsung.com>
Now that we have a new header file for cache-aligned allocation, we should
move the stack-based allocation macro there also.
Signed-off-by: Simon Glass <sjg@chromium.org>
After rework of the file system API, the size of ext4
write was missed. This causes printing unreliable write
size at the end of the file system write operation.
Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com>
Cc: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Cc: Simon Glass <sjg@chromium.org>
Tested-by: Stephen Warren <swarren@nvidia.com>
Change the internal EXT4 functions to use loff_t for offsets.
Signed-off-by: Suriyan Ramasami <suriyan.r@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
[trini: Update common/spl/spl_ext.c]
Signed-off-by: Tom Rini <trini@ti.com>
Since ALLOC_CACHE_ALIGN_BUFFER declares a char* for filename
sizeof(filename) is not the size of the buffer. Use the already
known length instead.
cc: Uma Shankar <uma.shankar@samsung.com>
cc: Manjunatha C Achar <a.manjunatha@samsung.com>
cc: Marek Vasut <marek.vasut@gmail.com>
Signed-off-by: Jeroen Hofstee <jeroen@myspectrum.nl>
Acked-by: Marek Vasut <marex@denx.de>
This bug shows up when file stored on the ext4 file system is updated.
The ext4fs_delete_file() is responsible for deleting file's (e.g. uImage)
data.
However some global data (especially ext4fs_indir2_block), which is used
during file deletion are left unchanged.
The ext4fs_indir2_block pointer stores reference to old ext4 double
indirect allocated blocks. When it is unchanged, after file deletion,
ext4fs_write_file() uses the same pointer (since it is already initialized
- i.e. not NULL) to return number of blocks to write. This trunks larger
file when previous one was smaller.
Lets consider following scenario:
1. Flash target with ext4 formatted boot.img (which has uImage [*] on itself)
2. Developer wants to upload their custom uImage [**]
- When new uImage [**] is smaller than the [*] - everything works
correctly - we are able to store the whole smaller file with corrupted
ext4fs_indir2_block pointer
- When new uImage [**] is larger than the [*] - theCRC is corrupted,
since truncation on data stored at eMMC was done.
3. When uImage CRC error appears, then reboot and LTHOR/DFU reflashing causes
proper setting of ext4fs_indir2_block() and after that uImage[**]
is successfully stored (correct uImage [*] metadata is stored at an
eMMC on the first flashing).
Due to above the bug was very difficult to reproduce.
This patch sets default values for all ext4fs_indir* pointers/variables.
Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
Code responsible for handling situation when ext4 has block size of 1024B
can be ordered to take less space.
This patch does that for ext4 common and write files.
Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
Curently, we are using 32 bit multiplication to calculate the offset,
so the result will always be 32 bit.
This can silently cause file system corruption when performing a write
operation on partition larger than 4 GiB.
This patch address the issue by simply promoting the terms to 64 bit,
and let compilers decide how to do the multiplication efficiently.
Signed-off-by: Ma Haijun <mahaijuns@gmail.com>
With CONFIG_SYS_64BIT_LBA, lbaint_t gets defined as a 64-bit type,
which is required to represent block numbers for storage devices that
exceed 2TiB (the block size usually is 512B), e.g. recent hard drives
We now use lbaint_t for partition offset to reflect the lbaint_t change,
and access partitions beyond or crossing the 2.1TiB limit.
This required changes to signature of ext4fs_devread(), and type of all
variables relatives to block sector.
ext2/ext4 fs uses logical block represented by a 32 bit value. Logical
block is a multiple of device block sector. To avoid overflow problem
when calling ext4fs_devread(), we need to cast the sector parameter.
Signed-off-by: Frédéric Leroy <fredo@starox.org>
The 512 byte block size was hard coded in the ext4 file systems.
Large harddisks today support bigger block sizes typically 4096
bytes.
This patch removes this limitation.
Signed-off-by: Egbert Eich <eich@suse.com>
This code seems to be entirely othogonal, so remove the #ifdef and put
the condition in the Makefile instead.
Signed-off-by: Simon Glass <sjg@chromium.org>
