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>
If the blocksize is 1024, count is initialized with 1. Incrementing count
by 8 will never match (count == fs->blksz * 8), and ptr may be
incremented beyond the buffer end if the bitmap is filled. Add the
startblock offset after the loop.
Remove the second loop, as only the first iteration will be done.
Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
Reviewed-by: Lukasz Majewski <l.majewski@samsung.com>
The last free block of a block group may be in its middle. After it has
been allocated, the next block group should be scanned from its beginning.
The following command triggers the bad behaviour (on a blocksize 1024 fs):
./sandbox/u-boot -c 'i=0; host bind 0 ./disk.raw ;
while test $i -lt 260 ; do echo $i; setexpr i $i + 1;
ext4write host 0:2 0 /X${i} 0x1450; done ;
ext4write host 0:2 0 /X240 0x2000 ; '
When 'X240' is extended from 5200 byte to 8192 byte, the new blocks should
start from the first free block (8811), but it uses the blocks 8098-8103
and 16296-16297 -- 8103 + 1 + 8192 = 16296. This can be shown with
debugfs, commands 'ffb' and 'stat X240'.
Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
Reviewed-by: Lukasz Majewski <l.majewski@samsung.com>
zero_buffer is never written, thus clearing it is pointless.
journal_buffer is completely initialized by ext4fs_devread (or in case
of failure, not used).
Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
Reviewed-by: Lukasz Majewski <l.majewski@samsung.com>
e2fsck warns about "Group descriptor 0 marked uninitialized without
feature set."
The bg_itable_unused field is only defined if FEATURE_RO_COMPAT_GDT_CSUM
is set, and should be set (kept) zero otherwise.
Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
Reviewed-by: Lukasz Majewski <l.majewski@samsung.com>
Scanning only the direct blocks of the directory file may falsely report
an existing file as nonexisting, and worse can also lead to creation
of a duplicate entry on file creation.
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>
Previously, only the last directory block was scanned for available space.
Instead, scan all blocks back to front, and if no sufficient space is
found, eventually append a new block.
Blocks are only appended if the directory does not use extents or the new
block would require insertion of indirect blocks, as the old code does.
Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
Reviewed-by: Lukasz Majewski <l.majewski@samsung.com>
The following command crashes u-boot:
./sandbox/u-boot -c 'i=0; host bind 0 ./sandbox/test/fs/3GB.ext4.img ;
while test $i -lt 200 ; do echo $i; setexpr i $i + 1;
ext4write host 0 0 /foobar${i} 0; done'
Previously, the code updated the direct_block even for extents, and
fortunately crashed before pushing garbage to the disk.
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>
Change all the types of ext2/4 fields to little endian types and all the
JBD fields to big endian types. Now we can use sparse (make C=1) to check
for statements where we need byteswaps.
Signed-off-by: Michael Walle <michael@walle.cc>
With e2fsprogs after 1.43 the 64bit and metadata_csum features are
enabled by default. The metadata_csum feature changes how
ext4_group_desc->bg_checksum is calculated, which would break write
support. The 64bit feature however introduces changes such that it
cannot be read by implementations that do not support it. Since we do
not support this, we must not mount it.
Cc: Stephen Warren <swarren@nvidia.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Cc: Stefan Roese <sr@denx.de>
Reported-by: Andrew Bradford <andrew.bradford@kodakalaris.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
The function ext4fs_read_symlink was unable to handle a symlink
which had target name of exactly 60 characters.
Signed-off-by: Ronald Zachariah <rozachar@cisco.com>
Signed-off-by: Stefan Roese <sr@denx.de>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Cc: Tom Rini <trini@konsulko.com>
To ease conversion to driver model, add helper functions which deal with
calling each block device method. With driver model we can reimplement these
functions with the same arguments.
Use inline functions to avoid increasing code size on some boards.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Stephen Warren <swarren@nvidia.com>
Use 'struct' instead of a typdef. Also since 'struct block_dev_desc' is long
and causes 80-column violations, rename it to struct blk_desc.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Stephen Warren <swarren@nvidia.com>
As noted by Coverity, when we have an error in
alloc_triple_indirect_block we will leak ti_pbuff_start_addr as it's not
being freed. Further inspection here shows that we could also leak
ti_cbuff_start_addr in one corner case so free that as well.
Reported-by: Coverity (CID 131205, 131206)
Signed-off-by: Tom Rini <trini@konsulko.com>
This will allow the implementation to make use of data in the block_dev
structure beyond the base device number. This will be useful so that eMMC
block devices can encompass the HW partition ID rather than treating this
out-of-band. Equally, the existence of the priv field is crying out for
this patch to exist.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
If the ext3 journal gets out of sync with what is written on disk, for
example because of an unexpected power cut, ext4fs_read_file can
return an all-zero directory entry. In that case, ext4fs_iterate_dir
would infinite loop.
This patch detects when a directory entry's direntlen member is 0 and
returns a failure status, which breaks out of the infinite loop. As a
result, U-Boot will not find files that may subsequently be recovered
when the journal is replayed.
This is better behaviour than hanging in an infinite loop, but as a
further improvement maybe U-Boot could interpret the ext3 journal and
actually find the unsynced entries.
Signed-off-by: Thomas Fitzsimmons <fitzsim@cisco.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Since last API changes for files >2GB, the read of symlink is broken as
ext4fs_read_file now returns 0 instead of the length of the actual read.
Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com>
root_first_block_buffer should be free()d in all cases, not just when an
error occurs. Fix the success exit path of the function to do this.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Lukasz Majewski <l.majewski@samsung.com>
Tested-by: Lukasz Majewski <l.majewski@samsung.com>
parse_path() malloc()s the entries in the array it's passed. Those
allocations must be free()d by the caller, ext4fs_get_parent_inode_num().
Add code to do this.
For this to work, all the array entries must be dynamically allocated,
rather than a mix of dynamic and static allocations. Fix parse_path() not
to over-write arr[0] with a pointer to statically allocated data.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Lukasz Majewski <l.majewski@samsung.com>
Tested-by: Lukasz Majewski <l.majewski@samsung.com>
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>
The changes to introduce loff_t into filesize means that we need to do
64bit math on 32bit platforms. Make sure we use the right wrappers for
these operations.
Cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Cc: Suriyan Ramasami <suriyan.r@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@ti.com>
Tested-by: Pierre Aubert <p.aubert@staubli.com>
The sandbox/ext4/fat/generic fs commands do not gracefully deal with files
greater than 2GB. Negative values are returned in such cases.
To handle this, the fs functions have been modified to take an additional
parameter of type "* loff_t" which is then populated. The return value
of the fs functions are used only for error conditions.
Signed-off-by: Suriyan Ramasami <suriyan.r@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
[trini: Update board/gdsys/p1022/controlcenterd-id.c,
drivers/fpga/zynqpl.c for changes]
Signed-off-by: Tom Rini <trini@ti.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>
Some filesystems have a UUID stored in its superblock. To
allow using root=UUID=... for the kernel command line we
need a way to read-out the filesystem UUID.
changes rfc -> v1:
- make the environment variable an option parameter. If not
given, the UUID is printed out. If given, it is stored in the env
variable.
- corrected typos
- return error codes
changes v1 -> v2:
- fix return code of do_fs_uuid(..)
- document do_fs_uuid(..)
- implement fs_uuid_unsuported(..) be more consistent with the
way other optional functionality works
changes v2 -> v3:
- change ext4fs_uuid(..) to make use of #if .. #else .. #endif
construct to get rid of unreachable code
Hit any key to stop autoboot: 0
=> fsuuid
fsuuid - Look up a filesystem UUID
Usage:
fsuuid <interface> <dev>:<part>
- print filesystem UUID
fsuuid <interface> <dev>:<part> <varname>
- set environment variable to filesystem UUID
=> fsuuid mmc 0:1
d9f9fc05-45ae-4a36-a616-fccce0e4f887
=> fsuuid mmc 0:2
eb3db83c-7b28-499f-95ce-9e0bb21cda81
=> fsuuid mmc 0:1 uuid1
=> fsuuid mmc 0:2 uuid2
=> printenv uuid1
uuid1=d9f9fc05-45ae-4a36-a616-fccce0e4f887
=> printenv uuid2
uuid2=eb3db83c-7b28-499f-95ce-9e0bb21cda81
=>
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Acked-by: Stephen Warren <swarren@nvidia.com>
U-Boot has never cared about the type when we get max/min of two
values, but Linux Kernel does. This commit gets min, max, min3, max3
macros synced with the kernel introducing type checks.
Many of references of those macros must be fixed to suppress warnings.
We have two options:
- Use min, max, min3, max3 only when the arguments have the same type
(or add casts to the arguments)
- Use min_t/max_t instead with the appropriate type for the first
argument
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Acked-by: Pavel Machek <pavel@denx.de>
Acked-by: Lukasz Majewski <l.majewski@samsung.com>
Tested-by: Lukasz Majewski <l.majewski@samsung.com>
[trini: Fixup arch/blackfin/lib/string.c]
Signed-off-by: Tom Rini <trini@ti.com>
On 64-bit platforms (like sandbox) 64-bit integers may be 'long' rather
than 'long long'. Use the inttypes header to avoid compiler warnings.
Signed-off-by: Simon Glass <sjg@chromium.org>
This would be useful to start moving various config options.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Acked-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
These commands may be used to determine the size of a file without
actually reading the whole file content into memory. This may be used
to determine if the file will fit into the memory buffer that will
contain it. In particular, the DFU code will use it for this purpose
in the next commit.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
ext4fs_allocate_blocks() always allocates at least one block for a file.
If the file size is zero, this causes total_remaining_blocks to
underflow, which then causes an apparent hang while 2^32 blocks are
allocated.
To solve this, check that total_remaining_blocks is non-zero as part of
the loop condition (i.e. before each loop) rather than at the end of
the loop.
Signed-off-by: Stephen Warren <swarren@nvidia.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>
This reverts commit fc0fc50f38.
The author has asked on the mailing list that we revert this for now as
it breaks write support.
Reported-by: Łukasz Majewski <l.majewski@samsung.com>
Signed-off-by: Tom Rini <trini@ti.com>
In an ext4 filesystem, the inode corresponding to a file has a 60-byte
area which contains an extent header structure and up to 4 extent
structures (5 x 12 bytes).
For files that need more than 4 extents to be represented (either files
larger than 4 x 128MB = 512MB or smaller files but very fragmented),
ext4 creates extent index structures. Each extent index points to a 4KB
physical block where one extent header and additional 340 extents could
be stored.
The current u-boot ext4 code is very inefficient when it tries to load a
file which has extent indexes. For each logical file block the code will
read over and over again the same blocks of 4096 bytes from the disk.
Since the extent tree in a file is always the same, we can cache the
extent structures in memory before actually starting to read the file.
This patch creates a simple linked list of structures holding information
about all the extents used to represent a file. The list is sorted by
the logical block number (ee_block) so that we can easily find the
proper extent information for any file block.
Without this patch, a 69MB file which had just one extent index pointing
to a block with another 6 extents was read in approximately 3 minutes.
With this patch applied the same file can be read in almost 20 seconds.
Signed-off-by: Ionut Nicu <ioan.nicu.ext@nsn.com>
This hooks into the generic "file exists" support added in an earlier
patch, and provides an implementation for the ext4 filesystem.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Simon Glass <sjg@chromium.org>
For files where we actually have extent indexes following
an extent header (ext_block->eh_depth != 0), the do/while
loop from ext4fs_get_extent_block() does not select the
proper extent index structure.
For example, if we have:
ext_block->eh_depth = 1
ext_block->eh_entries = 1
fileblock = 0
index[0].ei_block = 0
the do/while loop will exit with i set to 0 and the
ext4fs_get_extent_block() function will return 0, even if
there was a valid extent index structure following the
header.
Signed-off-by: Ionut Nicu <ioan.nicu.ext@nsn.com>
Signed-off-by: Mathias Rulf <mathias.rulf@nsn.com>
Using fs->blksz in ext4fs_get_extent_block() is not
correct since fs->blksz is not initialized on the
read path. Use EXT2_BLOCK_SIZE() instead which will
produce the desired output.
Signed-off-by: Ionut Nicu <ioan.nicu.ext@nsn.com>
Signed-off-by: Mathias Rulf <mathias.rulf@nsn.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>
