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>
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>
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>
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>
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>
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>
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>
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>
Fix reading ext4_extent_header struture on BE machines. Some 16 bit
fields where converted to 32 bit fields, due to the byte swap on BE
machines the containing value was corrupted. Therefore reading ext4
filesystems on BE machines where broken before.
Signed-off-by: Rommel Custodio <sessyargc+uboot@gmail.com>
[sent via git-send-email; rework commit message]
Signed-off-by: Andreas Bießmann <andreas.devel@googlemail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
Tested-by: Lukasz Majewski <l.majewski@samsung.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 makes the FAT and ext4 filesystem implementations build if
CONFIG_FS_{FAT,EXT4} are defined, rather than basing the build on
whether CONFIG_CMD_{FAT,EXT*} are defined. This will allow the
filesystems to be built separately from the filesystem-specific commands
that use them. This paves the way for the creation of filesystem-generic
commands that used the filesystems, without requiring the filesystem-
specific commands.
Minor documentation changes are made for this change.
The new config options are automatically selected by the old config
options to retain backwards-compatibility.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
On x86 machines gd is unfortunately a #define, so we should avoid using
gd for anything. This patch changes uses of gd to bgd so that ext4fs
can be used on x86.
A better fix would be to remove the #define in x86, but I'm not sure
how to do that.
Signed-off-by: Simon Glass <sjg@chromium.org>
DMA buffer cache invalidation requires that buffers have cache-aligned
buffer locations and sizes. Use memalign() and ALLOC_CACHE_ALIGN_BUFFER()
to ensure this.
On Tegra at least, without this fix, the following fail commands fail in
u-boot-master/ext4, but succeeded at the branch's branch point in
u-boot/master. With this fix, the commands work again:
ext2ls mmc 0:1 /
ext2load mmc 0:1 /boot/zImage
Cc: Uma Shankar <uma.shankar@samsung.com>
Cc: Manjunatha C Achar <a.manjunatha@samsung.com>
Cc: Iqbal Shareef <iqbal.ams@samsung.com>
Cc: Hakgoo Lee <goodguy.lee@samsung.com>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Tom Rini <trini@ti.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Ronald Zachariah