This is the case when reading freshly created filesystem.
The error message is like the following:
    btrfs_read_superblock: No valid root_backup found!

Since the data from super_roots/root_backups is not actually used -
decided to rework btrfs_newest_root_backup() into
btrfs_check_super_roots() that will only check if super_roots
array is valid and correctly handle empty scenario.

As a result:
* btrfs_read_superblock() now only checks if super_roots array is valid;
  the case when it is empty is considered OK.
* removed root_backup pointer from btrfs_info,
  which would be NULL in case of empty super_roots.
* btrfs_read_superblock() verifies number of devices from the superblock
  itself, not newest root_backup.

Signed-off-by: Yevgeny Popovych <yevgenyp@pointgrab.com>
Cc: Marek Behun <marek.behun@nic.cz>
Cc: Sergey Struzh <sergeys@pointgrab.com>

Often during debugging session it's very interesting to see
what data we were dealing with. For example what we write or read
to/from memory or peripherals.

This change introduces functions that allow to dump binary
data with one simple function invocation like:
------------------->8----------------
print_hex_dump_bytes("", DUMP_PREFIX_OFFSET, buf, len);
------------------->8----------------

which gives us the following:
------------------->8----------------
00000000: f2 b7 c9 88 62 61 75 64 72 61 74 65 3d 31 31 35  ....baudrate=115
00000010: 32 30 30 00 62 6f 6f 74 61 72 67 73 3d 63 6f 6e  200.bootargs=con
00000020: 73 6f 6c 65 3d 74 74 79 53 33 2c 31 31 35 32 30  sole=ttyS3,11520
00000030: 30 6e 38 00 62 6f 6f 74 64 65 6c 61 79 3d 33 00  0n8.bootdelay=3.
00000040: 62 6f 6f 74 66 69 6c 65 3d 75 49 6d 61 67 65 00  bootfile=uImage.
00000050: 66 64 74 63 6f 6e 74 72 6f 6c 61 64 64 72 3d 39  fdtcontroladdr=9
00000060: 66 66 62 31 62 61 30 00 6c 6f 61 64 61 64 64 72  ffb1ba0.loadaddr
00000070: 3d 30 78 38 32 30 30 30 30 30 30 00 73 74 64 65  =0x82000000.stde
00000080: 72 72 3d 73 65 72 69 61 6c 30 40 65 30 30 32 32  rr=serial0@e0022
00000090: 30 30 30 00 73 74 64 69 6e 3d 73 65 72 69 61 6c  000.stdin=serial
000000a0: 30 40 65 30 30 32 32 30 30 30 00 73 74 64 6f 75  0@e0022000.stdou
000000b0: 74 3d 73 65 72 69 61 6c 30 40 65 30 30 32 32 30  t=serial0@e00220
000000c0: 30 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00  00..............
...
------------------->8----------------

Source of hexdump.c was copied from Linux kernel v4.7-rc2.

Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Anatolij Gustschin <agust@denx.de>
Cc: Mario Six <mario.six@gdsys.cc>
Cc: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
Cc: Stefan Roese <sr@denx.de>

This causes errors when translating logical addresses to physical:
  btrfs_map_logical_to_physical: Cannot map logical address <addr> to physical
  btrfs_file_read: Error reading extent

The behavior of btrfs_map_logical_to_physical() is to stop traversing
CHUNK_TREE when it encounters first non-CHUNK_ITEM, which makes
only some portion of CHUNK_ITEMs being read.
Change it to skip over non-chunk items.

Signed-off-by: Yevgeny Popovych <yevgenyp@pointgrab.com>
Cc: Marek Behun <marek.behun@nic.cz>
Cc: Sergey Struzh <sergeys@pointgrab.com>
Reviewed-by: Marek Behun <marek.behun@nic.cz>

Add fs_get_type_name so we can get the current filesystem type.

Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Joe Hershberger <joe.hershberger@ni.com>

Found a crash while issuing ext4ls with a non-existent directory.
Crash test:

=> ext4ls mmc 0 1
** Can not find directory. **
data abort
pc : [<3fd7c2ec>]          lr : [<3fd93ed8>]
reloc pc : [<26f142ec>]    lr : [<26f2bed8>]
sp : 3f963338  ip : 3fdc3dc4     fp : 3fd6b370
r10: 00000004  r9 : 3f967ec0     r8 : 3f96db68
r7 : 3fdc99b4  r6 : 00000000     r5 : 3f96dc88  r4 : 3fdcbc8c
r3 : fffffffa  r2 : 00000000     r1 : 3f96e0bc  r0 : 00000002
Flags: nZCv  IRQs off  FIQs off  Mode SVC_32
Resetting CPU ...

resetting ...

Tested on SAMA5D2_Xplained board (sama5d2_xplained_mmc_defconfig)

Looks like crash is introduced by commit:
"fa9ca8a5" fs/ext4/ext4fs.c: Free dirnode in error path of ext4fs_ls

Issue is that dirnode is not initialized, and then freed if the call
to ext4_ls fails. ext4_ls will not change the value of dirnode in this case
thus we have a crash with data abort.

I added initialization and a check for dirname being NULL.

Fixes: "fa9ca8a5" fs/ext4/ext4fs.c: Free dirnode in error path of ext4fs_ls
Cc: Stefan Brüns <stefan.bruens@rwth-aachen.de>
Cc: Tom Rini <trini@konsulko.com>
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

This patch solves assert failed displayed in the console during a boot.
The root cause is that the ubifs_inode is not already allocated when
ubifs_printdir and ubifs_finddir functions are called.

Trace showing the issue:
feed 'boot.scr.uimg', ino 94, new f_pos 0x17b40ece
dent->ch.sqnum '7132', creat_sqnum 3886945402880
UBIFS assert failed in ubifs_finddir at 436
INODE ALLOCATION: creat_sqnum '7129'
Found U-Boot script /boot.scr.uimg

Signed-off-by: Christophe Kerello <christophe.kerello@st.com>
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>

When U-Boot started using SPDX tags we were among the early adopters and
there weren't a lot of other examples to borrow from.  So we picked the
area of the file that usually had a full license text and replaced it
with an appropriate SPDX-License-Identifier: entry.  Since then, the
Linux Kernel has adopted SPDX tags and they place it as the very first
line in a file (except where shebangs are used, then it's second line)
and with slightly different comment styles than us.

In part due to community overlap, in part due to better tag visibility
and in part for other minor reasons, switch over to that style.

This commit changes all instances where we have a single declared
license in the tag as both the before and after are identical in tag
contents.  There's also a few places where I found we did not have a tag
and have introduced one.

Signed-off-by: Tom Rini <trini@konsulko.com>

The mutex lock and unlock functions are stubbed out and mutex_is_locked
was 0.  This caused asserts to fail in ubifs code when checking that the
mutex was locked.  For example,

UBIFS assert failed in ubifs_change_lp at 540
UBIFS assert failed in ubifs_release_lprops at 278

Assume that the "mutex" is locked since that is the normal case when it
is checked in the ubifs code.

Signed-off-by: Bradley Bolen <bradleybolen@gmail.com>

Signed-off-by: Marek Behun <marek.behun@nic.cz>

The value at the end of the rom is not a pointer, it is an offset
relative to the end of rom.

Signed-off-by: Andre Heider <a.heider@gmail.com>

Introduce another difference from upstream (kernel) source in
fs/ubifs/super.c: adding preprocessor condition as y variable in
mount_ubifs() depends on CONFIG_UBIFS_SILENCE_MSG:
fs/ubifs/super.c:1337:15: error: variable ?y? set but not used [-Werror=unused-but-set-variable]
  long long x, y;

Not setting CONFIG_UBIFS_SILENCE_MSG in am335x_igep003x_defconfig and
igep0032_defconfig. Although it was defined in their config headers, it
depends on CMD_UBIFS which is not set for them.

Signed-off-by: Petr Vorel <petr.vorel@gmail.com>
Cc: Joe Hershberger <joe.hershberger@ni.com>
Cc: Heiko Schocher <hs@denx.de>

Use of CONFIG_UBIFS_SILENCE_MSG was added in
147162da ("ubi: ubifs: Turn off verbose prints")

Then it was removed in
ff94bc40 ("mtd, ubi, ubifs: resync with Linux-3.14")

Cc: Joe Hershberger <joe.hershberger@ni.com>
Cc: Heiko Schocher <hs@denx.de>
Signed-off-by: Petr Vorel <petr.vorel@gmail.com>

Other filesystem drivers don't do this.

Signed-off-by: Marek Behun <marek.behun@nic.cz>

The iterator of list_for_each() is never NULL.

Identified with coccinelle.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

When printing a size_t value we need to use %zu for portability between
32bit and 64bit targets.

Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Marek Behun <marek.behun@nic.cz>

Loading files stored with lzo compression from a btrfs filesystem was
producing unaligned memory accesses, which were causing a data abort
and a reset on an Orange Pi Zero.

The change in hash.c is not triggered by any error but follows the
same pattern. Please confirm.

Fixed according to doc/README.unaligned-memory-access.txt

Signed-off-by: Alberto Sánchez Molero <alsamolero@gmail.com>
Tested-by: Robert Nelson <robertcnelson@gmail.com>

fat.h unconditionally defines CONFIG_SUPPORT_VFAT (and has done since
2003), so as a result VFAT support is always enabled regardless of
whether a board config defines it or not. Drop this unnecessary option.

Signed-off-by: Tuomas Tynkkynen <tuomas@tuxera.com>

Signed-off-by: Tuomas Tynkkynen <tuomas@tuxera.com>

Migrate the following symbols to Kconfig:

CONFIG_FS_EXT4
CONFIG_EXT4_WRITE

The definitions in config_fallbacks.h can now be expressed in Kconfig.

Signed-off-by: Tuomas Tynkkynen <tuomas@tuxera.com>

The message "reading %s\n" may be interesting when
debugging but otherwise it is superfluous.

Only output the message when debugging.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>

The message
"** %s shorter than offset + len **\n"
may be interesting when debugging but it does not indicate an
error.

So we should not write it if we are not in debug mode.

Fixes: 7a3e70cf fs/fs.c: read up to EOF when len would read past EOF
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>

commit 21a24c3b ("fs/fat: fix case for FAT shortnames") made it
possible that get_name() returns file names with some upper cases.
find_directory_entry() must be updated to take this account, and use
case-insensitive functions to compare file names.

Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>

This header was renamed to rawnand.h in Linux.

The following is the corresponding commit in Linux.

  commit d4092d76a4a4e57b65910899948a83cc8646c5a5
  Author: Boris Brezillon <boris.brezillon@free-electrons.com>
  Date:   Fri Aug 4 17:29:10 2017 +0200

      mtd: nand: Rename nand.h into rawnand.h

      We are planning to share more code between different NAND based
      devices (SPI NAND, OneNAND and raw NANDs), but before doing that
      we need to move the existing include/linux/mtd/nand.h file into
      include/linux/mtd/rawnand.h so we can later create a nand.h header
      containing all common structure and function prototypes.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Before this patch one could receive following errors when executing "fatls"
command on machine with cache enabled (ex i.MX6Q) :

=> fatls mmc 0:1
CACHE: Misaligned operation at range [4f59dfc8, 4f59e7c8]
CACHE: Misaligned operation at range [4f59dfc8, 4f59e7c8]
ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x4f59dfc8
ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x4f59e7c8
CACHE: Misaligned operation at range [4f59dfc8, 4f59e7c8]
CACHE: Misaligned operation at range [4f59dfc8, 4f59e7c8]
ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x4f59dfc8
ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x4f59e7c8

To alleviate this problem - the calloc()s have been replaced with
malloc_cache_aligned() and memset().

After those changes the buffers are properly aligned (with both start
address and size) to SoC cache line.

Fixes: 09fa964b ("fs/fat: Fix 'CACHE: Misaligned operation at range' warnings")
Suggested-by: Lukasz Majewski <lukma@denx.de>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>

It is unwise to first dereference a variable
and then to check if it was NULL.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Marek Behun <marek.behun@nic.cz>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

The iterator variable of list_for_each is never NULL.
if (1 || A) is always true.
Use break if entry found.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

kfree() calls free.
free() checks if the parameter is NULL.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

Some fixes when reading EXT files and directory entries were identified
after using e2fuzz to corrupt an EXT3 filesystem:

 - Stop reading directory entries if the offset becomes badly aligned.

 - Avoid overwriting memory by clamping the length used to zero the buffer
   in ext4fs_read_file.  Also sanity check blocksize.

Signed-off-by: Ian Ray <ian.ray@ge.com>
Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk>
Reviewed-by: Stefano Babic <sbabic@denx.de>

All users of this macro have been converted.  Remove MTDDEBUG and
related CONFIG options.

ubifs_dbg_msg_key() is kept.  It is silent unless DEBUG is defined.

I am not touching scripts/config_whitelist.txt.  The deprecated options
will be dropped by the next resync.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

This makes gcc no longer expect an out-of-line version of the
functions being present elsewhere.

This fixes a failure to build on several marvell targets with gcc-7 on
Debian:

  https://bugs.debian.org/877963



Signed-off-by: Adrian Bunk <bunk@debian.org>
Signed-off-by: Vagrant Cascadian <vagrant@debian.org>

Hello,

I ran into a problem with the JFFS2 filesystem driver implemented in U-Boot.

I've got a NAND device that has correctable ECC errors (corrected somewhere in mtd/nand/nand_base.c).
The NAND driver tells the filesystem layer (jffs2_1pass.c) above that there occurred correctable ECC errors and returns with a "value > 0".
The JFFS2 driver recognizes the corrected ECC errors as real error and skips this block because the only accepts a "return value == 0" as correct.

This problem exists for over 8 years (I checked version 2010.09) so I'm a little bit worried that I interpreted something wrong or didn't get the whole context.

Can someone confirm this bug (and the bugfix) in the u-boot jffs2 driver?

There was a mail in 2012 that mentioned the same problem, but there was no patch:
http://u-boot.10912.n7.nabble.com/JFFS2-seems-to-drop-nand-data-with-ECC-corrections-td142008.html
Sometime after this discussion the return value of nand_read() changed from -EUCLEAN as correctable ECC error to a positive value with the count of ECC corrected errors.

With kind reguards,
Uwe Engling

Otherwise fs_opendir will fault.

Signed-off-by: Marek Behun <marek.behun@nic.cz>

I accidentaly left a foreign language note in the code from development.

Signed-off-by: Marek Behun <marek.behun@nic.cz>

The variable res should be initialized to 0 in these functions,
because if the searched key is not found, the variable is used
uninitialized.

Reported-by: Coverity (CID: 167335)
Reported-by: Coverity (CID: 167336)
Reported-by: Coverity (CID: 167337)
Signed-off-by: Marek Behun <marek.behun@nic.cz>

Check malloc() return values and properly unwind on errors so
memory allocated for fat_itr structures get freed properly.

Also fixes a leak of fsdata.fatbuf in fat_size().

Fixes: 2460098c ("fs/fat: Reduce stack usage")
Reported-by: Coverity (CID: 167225, 167233, 167234)
Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
Reviewed-by: Tom Rini <trini@konsulko.com>

The 'block' field of fat_itr needs to be properly aligned for DMA and
while it does have '__aligned(ARCH_DMA_MINALIGN)', the fat_itr structure
itself needs to be properly aligned as well.

While at it use malloc_cache_aligned() for the other aligned allocations
in the file as well.

Fixes: 2460098c ("fs/fat: Reduce stack usage")
Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
Reviewed-by: Tom Rini <trini@konsulko.com>

As reported by Coverity, we did not free dirnode in the case of failure.
Do so now.

Reported-by: Coverity (CID: 131221)
Cc: Stefan Brüns <stefan.bruens@rwth-aachen.de>
Signed-off-by: Tom Rini <trini@konsulko.com>

If we end up back in the root directory via a '..' directory entry, set
itr->is_root accordingly. Failing to do that gives spews like
"Invalid FAT entry" and being unable to access directory entries located
past the first cluster of the root directory.

Fixes: 8eafae20 ("fat/fs: convert to directory iterators")
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>

The current code doesn't compute the group descriptor checksum correctly
for the filesystems that e2fsprogs 1.43.4 creates (they have
'Group descriptor size: 64' as reported by tune2fs). Extend the checksum
calculation to be done as ext4_group_desc_csum() does in Linux.

This fixes these errors in dmesg from running fs-test.sh and makes it
succeed again:

[1671902.620699] EXT4-fs (loop1): ext4_check_descriptors: Checksum for group 0 failed (35782!=10965)
[1671902.620706] EXT4-fs (loop1): group descriptors corrupted!

Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>

U-Boot widely uses error() as a bit noisier variant of printf().

This macro causes name conflict with the following line in
include/linux/compiler-gcc.h:

  # define __compiletime_error(message) __attribute__((error(message)))

This prevents us from using __compiletime_error(), and makes it
difficult to fully sync BUILD_BUG macros with Linux.  (Notice
Linux's BUILD_BUG_ON_MSG is implemented by using compiletime_assert().)

Let's convert error() into now treewide-available pr_err().

Done with the help of Coccinelle, excluing tools/ directory.

The semantic patch I used is as follows:

// <smpl>
@@@@
-error
+pr_err
 (...)
// </smpl>

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
[trini: Re-run Coccinelle]
Signed-off-by: Tom Rini <trini@konsulko.com>