1. 27 Dec, 2016 1 commit
  2. 21 Nov, 2016 1 commit
  3. 24 Oct, 2016 3 commits
  4. 23 Sep, 2016 19 commits
  5. 05 Aug, 2016 1 commit
    • ext4: Refuse to mount filesystems with 64bit feature set · 6f94ab66
      Tom Rini authored
      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: 's avatarAndrew Bradford <andrew.bradford@kodakalaris.com>
      Signed-off-by: 's avatarTom Rini <trini@konsulko.com>
  6. 02 May, 2016 1 commit
  7. 14 Mar, 2016 1 commit
  8. 14 Jan, 2016 2 commits
  9. 23 Nov, 2015 1 commit
    • fs: ext4: Prevent infinite loop in ext4fs_iterate_dir · 54d68e93
      Thomas Fitzsimmons authored
      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: 's avatarThomas Fitzsimmons <fitzsim@cisco.com>
      Reviewed-by: 's avatarStefan Roese <sr@denx.de>
  10. 11 Sep, 2015 4 commits
  11. 23 Nov, 2014 1 commit
  12. 27 Oct, 2014 1 commit
  13. 19 Jun, 2014 1 commit
    • fs: ext4: fix writing zero-length files · d0180280
      Stephen Warren authored
      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: 's avatarStephen Warren <swarren@nvidia.com>
  14. 12 May, 2014 2 commits
    • fs:ext4:write:fix: Reinitialize global variables after updating a file · 8b454eee
      Łukasz Majewski authored
      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: 's avatarLukasz Majewski <l.majewski@samsung.com>
    • fs:ext4:cleanup: Remove superfluous code · 35dd055b
      Łukasz Majewski authored
      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: 's avatarLukasz Majewski <l.majewski@samsung.com>
  15. 26 Feb, 2014 1 commit