10 Apr, 2019

3 commits

  • 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
    Reviewed-by: Tom Rini
    [trini: Fix ext4 env code]
    Signed-off-by: Tom Rini

    Jean-Jacques Hiblot
     
  • 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
    Reviewed-by: Tom Rini

    Jean-Jacques Hiblot
     
  • 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

    Stephen Warren
     

23 Mar, 2019

1 commit

  • 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

    Sébastien Szymanski
     

22 Nov, 2016

1 commit


23 Sep, 2016

4 commits

  • 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 Brüns
     
  • If EXT4_FEATURE_INCOMPAT_64BIT is set, the descriptor can be read from
    the superblocks, otherwise it defaults to 32.

    Signed-off-by: Stefan Brüns

    Stefan Brüns
     
  • 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
    Reviewed-by: Lukasz Majewski

    Stefan Brüns
     
  • 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
    Reviewed-by: Lukasz Majewski

    Stefan Brüns
     

05 Aug, 2016

1 commit

  • 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
    Cc: Simon Glass
    Cc: Lukasz Majewski
    Cc: Stefan Roese
    Reported-by: Andrew Bradford
    Signed-off-by: Tom Rini

    Tom Rini
     

15 Mar, 2016

1 commit


23 Nov, 2014

3 commits

  • 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
    Acked-by: Simon Glass
    [trini: Update board/gdsys/p1022/controlcenterd-id.c,
    drivers/fpga/zynqpl.c for changes]
    Signed-off-by: Tom Rini

    Suriyan Ramasami
     
  • Change the internal EXT4 functions to use loff_t for offsets.

    Signed-off-by: Suriyan Ramasami
    Acked-by: Simon Glass
    [trini: Update common/spl/spl_ext.c]
    Signed-off-by: Tom Rini

    Suriyan Ramasami
     
  • 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 :
    - print filesystem UUID
    fsuuid :
    - 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
    Acked-by: Stephen Warren

    Christian Gmeiner
     

09 Aug, 2014

1 commit

  • 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

    Stephen Warren
     

13 May, 2014

1 commit

  • 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

    Łukasz Majewski
     

19 Feb, 2014

1 commit


16 Jul, 2013

1 commit

  • 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

    Frederic Leroy
     

10 May, 2013

1 commit


05 Mar, 2013

1 commit


30 Oct, 2012

1 commit

  • 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
    Reviewed-by: Benoît Thébaudeau

    Stephen Warren
     

04 Oct, 2012

1 commit


26 Sep, 2012

2 commits


10 Aug, 2012

2 commits