Skip to content
Snippets Groups Projects
  1. Dec 27, 2021
  2. Nov 05, 2021
  3. Oct 23, 2021
    • Marek Behún's avatar
      mtd: Remove mtd_erase_callback() entirely · 0d1ecc99
      Marek Behún authored and Jagan Teki's avatar Jagan Teki committed
      
      The original purpose of mtd_erase_callback() in Linux at the time it was
      imported to U-Boot, was to inform the caller that erasing is done (since
      it was an asynchronous operation).
      
      All supplied callback methods in U-Boot do nothing, but the
      mtd_erase_callback() function was (until previous patch) grossly abused
      in U-Boot's mtdpart implementation for completely different purpose.
      
      Since we got rid of the abusement, remove the mtd_erase_callback()
      function and the .callback member from struct erase_info entirely, in
      order to avoid such problems in the future.
      
      Signed-off-by: default avatarMarek Behún <marek.behun@nic.cz>
      0d1ecc99
  4. Oct 12, 2021
  5. Oct 08, 2021
  6. Oct 06, 2021
  7. Sep 30, 2021
  8. Sep 28, 2021
    • Heinrich Schuchardt's avatar
      fs: avoid superfluous messages · 00161538
      Heinrich Schuchardt authored and Ramon Fried's avatar Ramon Fried committed
      
      Output like the following is quite irritating:
      
          => bootefi hello
          Scanning disk mmc2.blk...
          No valid Btrfs found
          Bad magic number for SquashFS image.
          ** Unrecognized filesystem type **
          Scanning disk mmc1.blk...
          No valid Btrfs found
          Bad magic number for SquashFS image.
          ** Unrecognized filesystem type **
          Scanning disk mmc0.blk...
          No valid Btrfs found
          Bad magic number for SquashFS image.
          ** Unrecognized filesystem type **
      
      Albeit a whole disk may be formatted with a filesystem in most cases
      a partition table is used and the whole disk (partition number 0) doesn't
      contain a filesytem. Some partitions may only contain a blob. Not seeing a
      filesytem on the whole disk or on any partition is only worth a debug
      message.
      
      Signed-off-by: default avatarHeinrich Schuchardt <heinrich.schuchardt@canonical.com>
      Reviewed-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
      00161538
  9. Sep 24, 2021
    • Heinrich Schuchardt's avatar
      fs: avoid superfluous messages · 3bd0e2ca
      Heinrich Schuchardt authored and Tom Rini's avatar Tom Rini committed
      
      Output like the following is quite irritating:
      
          => bootefi hello
          Scanning disk mmc2.blk...
          No valid Btrfs found
          Bad magic number for SquashFS image.
          ** Unrecognized filesystem type **
          Scanning disk mmc1.blk...
          No valid Btrfs found
          Bad magic number for SquashFS image.
          ** Unrecognized filesystem type **
          Scanning disk mmc0.blk...
          No valid Btrfs found
          Bad magic number for SquashFS image.
          ** Unrecognized filesystem type **
      
      Albeit a whole disk may be formatted with a filesystem in most cases
      a partition table is used and the whole disk (partition number 0) doesn't
      contain a filesytem. Some partitions may only contain a blob. Not seeing a
      filesytem on the whole disk or on any partition is only worth a debug
      message.
      
      Signed-off-by: default avatarHeinrich Schuchardt <heinrich.schuchardt@canonical.com>
      Reviewed-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
      3bd0e2ca
  10. Sep 16, 2021
  11. Sep 01, 2021
    • Matwey V. Kornilov's avatar
      btrfs: Use default subvolume as filesystem root · 94509b79
      Matwey V. Kornilov authored and Tom Rini's avatar Tom Rini committed
      BTRFS volume consists of a number of subvolumes which can be mounted separately
      from each other. The top-level subvolume always exists even if no subvolumes
      were created manually. A subvolume can be denoted as the default subvolume i.e.
      the subvolume which is mounted by default.
      
      The default "default subvolume" is the top-level one, but this is far from the
      common practices used in the wild. For instance, openSUSE provides an OS
      snapshot/rollback feature based on BTRFS. To achieve this, the actual OS root
      filesystem is located into a separate subvolume which is "default" but not
      "top-level". That means that the /boot/dtb/ directory is also located inside
      this default subvolume instead of top-level one.
      
      However, the existing btrfs u-boot driver always uses the top-level subvolume
      as the filesystem root. This behaviour 1) is inconsistent with
      
          mount /dev/sda1 /target
      
      command, which mount the default subvolume 2) leads to the issues when
      /boot/dtb cannot be found properly (see the reference).
      
      This patch uses the default subvolume as the filesystem root to overcome
      mentioned issues.
      
      Reference: https://bugzilla.suse.com/show_bug.cgi?id=1185656
      
      
      Signed-off-by: default avatarMatwey V. Kornilov <matwey.kornilov@gmail.com>
      Fixes: f06bfcf5 ("fs: btrfs: Crossport open_ctree_fs_info() from btrfs-progs")
      Reviewed-by: default avatarQu Wenruo <wqu@suse.com>
      94509b79
  12. Aug 04, 2021
    • Campbell Suter's avatar
      fs/squashfs: Fix some hardlinks reading the wrong inode · a1ff2cb4
      Campbell Suter authored and Tom Rini's avatar Tom Rini committed
      
      In SquashFS, the contents of a directory is stored by
      squashfs_directory_entry structures which contain the file's name, inode
      and position within the filesystem.
      
      The inode number is not stored directly; instead each directory has one
      or more headers which set a base inode number, and files store the
      offset from that to the file's inode number.
      
      In mksquashfs, each inode is allocated a number in the same order as
      they are written to the directory table; thus the offset from the
      header's base inode number to the file's inode number is usually
      positive.
      
      Hardlinks are simply stored with two directory entries referencing the
      same file. This means the second entry will thus have an inode number
      much lower than the surrounding files. Since the header's base inode
      number comes from the first entry that uses the header, this delta will
      usually be negative.
      
      Previously, U-Boot's squashfs_directory_entry.inode_offset field was
      declared as an unsigned value. Thus when a negative value was found, it
      would either resolve to an invalid inode number or to that of an
      unrelated file.
      
      A squashfs image to test this can be created like so:
      
          echo hi > sqfs_test_files/001-root-file
          mkdir     sqfs_test_files/002-subdir
          touch     sqfs_test_files/002-subdir/003-file
          ln        sqfs_test_files/{001-root-file,002-subdir/004-link}
          mksquashfs sqfs_test_files/ test.sqfs -noappend
      
      Note that squashfs sorts the files ASCIIbetacally, so we can use the
      names to control the order they appear in. The ordering is important -
      the first reference to the file must have a lower inode number than the
      directory in which the second reference resides, and the second
      reference cannot be the first file in the directory.
      
      Listing this sample image in U-Boot results in:
      
      => sqfsls virtio 2 002-subdir
               0   003-file
      Inode not found.
               0   004-link
      
      Signed-off-by: default avatarCampbell Suter <campbell@snapit.group>
      Reviewed-by: default avatarMiquel Raynal <miquel.raynal@bootlin.com>
      a1ff2cb4
  13. Aug 02, 2021
  14. Jul 28, 2021
  15. Jul 15, 2021
  16. Jul 12, 2021
  17. Jun 10, 2021
    • Joao Marcos Costa's avatar
      fs/squashfs: fix reading of fragmented files · 0008d808
      Joao Marcos Costa authored and Tom Rini's avatar Tom Rini committed
      
      The fragmented files were not correctly read because of two issues:
      
      - The squashfs_file_info struct has a field named 'comp', which tells if
      the file's fragment is compressed or not. This field was always set to
      'true' in sqfs_get_regfile_info and sqfs_get_lregfile_info. It should
      actually take sqfs_frag_lookup's return value. This patch addresses
      these two assignments.
      
      - In sqfs_read, the fragments (compressed or not) were copied to the
      output buffer through a for loop which was reading data at the wrong
      offset. Replace these loops by equivalent calls to memcpy, with the
      right parameters.
      
      I tested this patch by comparing the MD5 checksum of a few fragmented
      files with the respective md5sum output in sandbox, considering both
      compressed and uncompressed fragments.
      
      Signed-off-by: default avatarJoao Marcos Costa <jmcosta944@gmail.com>
      Tested-by: default avatarRichard Genoud <richard.genoud@posteo.net>
      Reviewed-by: default avatarMiquel Raynal <miquel.raynal@bootlin.com>
      0008d808
  18. May 26, 2021
  19. Apr 28, 2021
  20. Apr 27, 2021
  21. Apr 22, 2021
  22. Apr 10, 2021
  23. Apr 07, 2021
    • Wagner Popov dos Santos's avatar
      JFFS2: fix jffs2 summary datacrc status uninitialized · fc25ffe7
      Wagner Popov dos Santos authored and Tom Rini's avatar Tom Rini committed
      
      The function jffs2_1pass_read_inode() was discarding the summary
      inodes and dirent because the value in datacrc flag wasn't
      initialized in function jffs2_sum_process_sum_data().
      
      This fix initializes the status of all summary records to indicate
      that the CRC needs to be verified when they are loaded.
      
      Before this fix, the behaviors produced by the undefined value of
      datacrc was:
      - Summary's registries were discarded when 'b->datacrc' is equal
        as 'CRC_BAD'.
      - Summary's registries were not checked when b->datacrc differs of
        'CRC_BAD' and 'CRC_UNKNOWN'
      
      So, almost all of the time the crc just isn't checked, and in some
      cases the registries are discarded.
      
      Signed-off-by: default avatarWagner Popov dos Santos <wpopov@gmail.com>
      fc25ffe7
    • Wagner Popov dos Santos's avatar
      JFFS2: fix the reading address over nand's limit · 610a2cc7
      Wagner Popov dos Santos authored and Tom Rini's avatar Tom Rini committed
      
      Fixes address violation in functions read_nand_cached() and
      read_onenand_cached(). This happens because these functions
      try to read a fixed amount
      of data even when the offset+length
      is above the nand's limit.
      
      Signed-off-by: default avatarWagner Popov dos Santos <wpopov@gmail.com>
      610a2cc7
  24. Mar 27, 2021
  25. Mar 04, 2021
  26. Mar 01, 2021
    • Marek Behún's avatar
      fs: btrfs: do not fail when offset of a ROOT_ITEM is not -1 · 1afb9f22
      Marek Behún authored and Tom Rini's avatar Tom Rini committed
      
      When the btrfs_read_fs_root() function is searching a ROOT_ITEM with
      location key offset other than -1, it currently fails via BUG_ON.
      
      The offset can have other value than -1, though. This can happen for
      example if a subvolume is renamed:
      
        $ btrfs subvolume create X && sync
        Create subvolume './X'
        $ btrfs inspect-internal dump-tree /dev/root | grep -B 2 'name: X$
              location key (270 ROOT_ITEM 18446744073709551615) type DIR
              transid 283 data_len 0 name_len 1
              name: X
        $ mv X Y && sync
        $ btrfs inspect-internal dump-tree /dev/root | grep -B 2 'name: Y$
              location key (270 ROOT_ITEM 0) type DIR
              transid 285 data_len 0 name_len 1
              name: Y
      
      As can be seen the offset changed from -1ULL to 0.
      
      Do not fail in this case.
      
      Signed-off-by: default avatarMarek Behún <marek.behun@nic.cz>
      Cc: David Sterba <dsterba@suse.com>
      Cc: Qu Wenruo <wqu@suse.com>
      Cc: Tom Rini <trini@konsulko.com>
      1afb9f22
  27. Feb 24, 2021
Loading