This allows us to have more context in ubifs_assert()
and take different actions depending on the configuration.
Signed-off-by: NRichard Weinberger <richard@nod.at>

Since commit 6da2ec56 ("treewide: kmalloc() -> kmalloc_array()")
we use kmalloc_array() for kmalloc() that computes the length with
a multiplication.

Cc: Kees Cook <keescook@chromium.org>
Suggested-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NRichard Weinberger <richard@nod.at>
Reviewed-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NRichard Weinberger <richard@nod.at>

Check whether the size is within bounds before using it.
If the size is not correct, abort and dump the bad data node.

Cc: Kees Cook <keescook@chromium.org>
Cc: Silvio Cesare <silvio.cesare@gmail.com>
Cc: stable@vger.kernel.org
Fixes: 1e51764a ("UBIFS: add new flash file system")
Reported-by: NSilvio Cesare <silvio.cesare@gmail.com>
Signed-off-by: NRichard Weinberger <richard@nod.at>
Reviewed-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NRichard Weinberger <richard@nod.at>

This reverts commit 353748a3.
It bypassed the linux-mtd review process and fixes the issue not as it
should.

Cc: Kees Cook <keescook@chromium.org>
Cc: Silvio Cesare <silvio.cesare@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: NRichard Weinberger <richard@nod.at>

Every single time I come across that code, I get confused
because it looks like a possible dead lock.
Help myself by adding a comment.
Signed-off-by: NRichard Weinberger <richard@nod.at>

In ubifs_jnl_update() we sync parent and child inodes to the flash,
in case of xattrs, the parent inode (AKA host inode) has a non-zero
data_len. Therefore we need to adjust synced_i_size too.

This issue was reported by ubifs self tests unter a xattr related work
load.
UBIFS error (ubi0:0 pid 1896): dbg_check_synced_i_size: ui_size is 4, synced_i_size is 0, but inode is clean
UBIFS error (ubi0:0 pid 1896): dbg_check_synced_i_size: i_ino 65, i_mode 0x81a4, i_size 4

Cc: <stable@vger.kernel.org>
Fixes: 1e51764a ("UBIFS: add new flash file system")
Signed-off-by: NRichard Weinberger <richard@nod.at>

There is potential for the size and len fields in ubifs_data_node to be
too large causing either a negative value for the length fields or an
integer overflow leading to an incorrect memory allocation. Likewise,
when the len field is small, an integer underflow may occur.
Signed-off-by: NSilvio Cesare <silvio.cesare@gmail.com>
Fixes: 1e51764a ("UBIFS: add new flash file system")
Cc: stable@vger.kernel.org
Signed-off-by: NKees Cook <keescook@chromium.org>

In the description of reserve_space() it is claimed that write_node()
and write_head() unlock the journal head. This is not true and has never
been true. All callers of write_node() and write_head() call
release_head() themselves. Remove the wrong comment.
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NRichard Weinberger <richard@nod.at>

We developed RENAME_EXCHANGE and UBIFS_FLG_DOUBLE_HASH more or less in
parallel and this case was forgotten. :-(

Cc: stable@vger.kernel.org
Fixes: d63d61c1 ("ubifs: Implement UBIFS_FLG_DOUBLE_HASH")
Signed-off-by: NRichard Weinberger <richard@nod.at>

When UBIFS prepares data structures which will be written to the MTD it
ensues that their lengths are multiple of 8. Since it uses kmalloc() the
padded bytes are left uninitialized and we leak a few bytes of kernel
memory to the MTD.
To make sure that all bytes are initialized, let's switch to kzalloc().
Kzalloc() is fine in this case because the buffers are not huge and in
the IO path the performance bottleneck is anyway the MTD.

Cc: stable@vger.kernel.org
Fixes: 1e51764a ("UBIFS: add new flash file system")
Signed-off-by: NRichard Weinberger <richard@nod.at>
Reviewed-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NRichard Weinberger <richard@nod.at>

If file names are encrypted we can no longer print them.
That's why we have to change these prints or remove them completely.
Signed-off-by: NRichard Weinberger <richard@nod.at>

When removing an encrypted file with a long name and without having
the key we have to be able to locate and remove the directory entry
via a double hash. This corner case was simply forgotten.

Fixes: 528e3d17 ("ubifs: Add full hash lookup support")
Reported-by: NDavid Oberhollenzer <david.oberhollenzer@sigma-star.at>
Signed-off-by: NRichard Weinberger <richard@nod.at>

Currently, the function truncate_data_node only updates the
destination data node size if compression is used. For
uncompressed nodes, the old length is incorrectly retained.

This patch makes sure that the length is correctly set when
compression is disabled.

Fixes: 7799953b ("ubifs: Implement encrypt/decrypt for all IO")
Signed-off-by: NDavid Oberhollenzer <david.oberhollenzer@sigma-star.at>
Signed-off-by: NRichard Weinberger <richard@nod.at>

Without this, I get the following on reboot:

UBIFS error (ubi1:0 pid 703): ubifs_load_znode: bad target node (type 1) length (8240)
UBIFS error (ubi1:0 pid 703): ubifs_load_znode: have to be in range of 48-4144
UBIFS error (ubi1:0 pid 703): ubifs_load_znode: bad indexing node at LEB 13:11080, error 5
 magic          0x6101831
 crc            0xb1cb246f
 node_type      9 (indexing node)
 group_type     0 (no node group)
 sqnum          546
 len            128
 child_cnt      5
 level          0
 Branches:
 0: LEB 14:72088 len 161 key (133, inode)
 1: LEB 14:81120 len 160 key (134, inode)
 2: LEB 20:26624 len 8240 key (134, data, 0)
 3: LEB 14:81280 len 160 key (135, inode)
 4: LEB 20:34864 len 8240 key (135, data, 0)
UBIFS warning (ubi1:0 pid 703): ubifs_ro_mode.part.0: switched to read-only mode, error -22
CPU: 0 PID: 703 Comm: mount Not tainted 4.9.0-next-20161213+ #1197
Hardware name: Atmel SAMA5
[<c010d2ac>] (unwind_backtrace) from [<c010b250>] (show_stack+0x10/0x14)
[<c010b250>] (show_stack) from [<c024df94>] (ubifs_jnl_update+0x2e8/0x614)
[<c024df94>] (ubifs_jnl_update) from [<c0254bf8>] (ubifs_mkdir+0x160/0x204)
[<c0254bf8>] (ubifs_mkdir) from [<c01a6030>] (vfs_mkdir+0xb0/0x104)
[<c01a6030>] (vfs_mkdir) from [<c0286070>] (ovl_create_real+0x118/0x248)
[<c0286070>] (ovl_create_real) from [<c0283ed4>] (ovl_fill_super+0x994/0xaf4)
[<c0283ed4>] (ovl_fill_super) from [<c019c394>] (mount_nodev+0x44/0x9c)
[<c019c394>] (mount_nodev) from [<c019c4ac>] (mount_fs+0x14/0xa4)
[<c019c4ac>] (mount_fs) from [<c01b5338>] (vfs_kern_mount+0x4c/0xd4)
[<c01b5338>] (vfs_kern_mount) from [<c01b6b80>] (do_mount+0x154/0xac8)
[<c01b6b80>] (do_mount) from [<c01b782c>] (SyS_mount+0x74/0x9c)
[<c01b782c>] (SyS_mount) from [<c0107f80>] (ret_fast_syscall+0x0/0x3c)
UBIFS error (ubi1:0 pid 703): ubifs_mkdir: cannot create directory, error -22
overlayfs: failed to create directory /mnt/ovl/work/work (errno: 22); mounting read-only

Fixes: 7799953b ("ubifs: Implement encrypt/decrypt for all IO")
Signed-off-by: NPeter Rosin <peda@axentia.se>
Tested-by: NKevin Hilman <khilman@baylibre.com>
Signed-off-by: NRichard Weinberger <richard@nod.at>

err is no longer being set on a successful return path, causing
a garbage value being returned. Fix this by setting err to zero
for the successful return path.

Found with static analysis by CoverityScan, CID 1389473

Fixes: 7799953b ("ubifs: Implement encrypt/decrypt for all IO")
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NRichard Weinberger <richard@nod.at>

This feature flag indicates that all directory entry nodes have a 32bit
cookie set and therefore UBIFS is allowed to perform lookups by hash.
Signed-off-by: NRichard Weinberger <richard@nod.at>

Signed-off-by: NRichard Weinberger <richard@nod.at>

UBIFS stores a 32bit hash of every file, for traditional lookups by name
this scheme is fine since UBIFS can first try to find the file by the
hash of the filename and upon collisions it can walk through all entries
with the same hash and do a string compare.
When filesnames are encrypted fscrypto will ask the filesystem for a
unique cookie, based on this cookie the filesystem has to be able to
locate the target file again. With 32bit hashes this is impossible
because the chance for collisions is very high. Do deal with that we
store a 32bit cookie directly in the UBIFS directory entry node such
that we get a 64bit cookie (32bit from filename hash and the dent
cookie). For a lookup by hash UBIFS finds the entry by the first 32bit
and then compares the dent cookie. If it does not match, it has to do a
linear search of the whole directory and compares all dent cookies until
the correct entry is found.
Signed-off-by: NRichard Weinberger <richard@nod.at>

Signed-off-by: NRichard Weinberger <richard@nod.at>
Signed-off-by: NDavid Gstir <david@sigma-star.at>
Signed-off-by: NRichard Weinberger <richard@nod.at>

Signed-off-by: NRichard Weinberger <richard@nod.at>
Signed-off-by: NDavid Gstir <david@sigma-star.at>
Signed-off-by: NRichard Weinberger <richard@nod.at>

When data of a data node is compressed and encrypted
we need to store the size of the compressed data because
before encryption we may have to add padding bytes.

For the new field we consume the last two padding bytes
in struct ubifs_data_node. Two bytes are fine because
the data length is at most 4096.
Signed-off-by: NRichard Weinberger <richard@nod.at>

...to make the code more consistent since we use
move already in other places.
Signed-off-by: NRichard Weinberger <richard@nod.at>

Adds RENAME_EXCHANGE to UBIFS, the operation itself
is completely disjunct from a regular rename() that's
why we dispatch very early in ubifs_reaname().

RENAME_EXCHANGE used by the renameat2() system call
allows the caller to exchange two paths atomically.
Both paths have to exist and have to be on the same
filesystem.
Signed-off-by: NRichard Weinberger <richard@nod.at>

Adds RENAME_WHITEOUT support to UBIFS, we implement
it in the same way as ext4 and xfs do.
For an overview of other ways to implement it please
refere to commit 7dcf5c3e ("xfs: add RENAME_WHITEOUT support").
Signed-off-by: NRichard Weinberger <richard@nod.at>

that's the bulk of filesystem drivers dealing with inodes of their own
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

In the case where we have more than one volumes on different UBI
devices, it may be not that easy to tell which volume prints the
messages.  Add ubi number and volume id in ubifs_msg/warn/error
to help debug. These two values are passed by struct ubifs_info.

For those where ubifs_info is not initialized yet, ubifs_* is
replaced by pr_*. For those where ubifs_info is not avaliable,
ubifs_info is passed to the calling function as a const parameter.

The output looks like,

[   95.444879] UBIFS (ubi0:1): background thread "ubifs_bgt0_1" started, PID 696
[   95.484688] UBIFS (ubi0:1): UBIFS: mounted UBI device 0, volume 1, name "test1"
[   95.484694] UBIFS (ubi0:1): LEB size: 126976 bytes (124 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
[   95.484699] UBIFS (ubi0:1): FS size: 30220288 bytes (28 MiB, 238 LEBs), journal size 1523712 bytes (1 MiB, 12 LEBs)
[   95.484703] UBIFS (ubi0:1): reserved for root: 1427378 bytes (1393 KiB)
[   95.484709] UBIFS (ubi0:1): media format: w4/r0 (latest is w4/r0), UUID 40DFFC0E-70BE-4193-8905-F7D6DFE60B17, small LPT model
[   95.489875] UBIFS (ubi1:0): background thread "ubifs_bgt1_0" started, PID 699
[   95.529713] UBIFS (ubi1:0): UBIFS: mounted UBI device 1, volume 0, name "test2"
[   95.529718] UBIFS (ubi1:0): LEB size: 126976 bytes (124 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
[   95.529724] UBIFS (ubi1:0): FS size: 19808256 bytes (18 MiB, 156 LEBs), journal size 1015809 bytes (0 MiB, 8 LEBs)
[   95.529727] UBIFS (ubi1:0): reserved for root: 935592 bytes (913 KiB)
[   95.529733] UBIFS (ubi1:0): media format: w4/r0 (latest is w4/r0), UUID EEB7779D-F419-4CA9-811B-831CAC7233D4, small LPT model

[  954.264767] UBIFS error (ubi1:0 pid 756): ubifs_read_node: bad node type (255 but expected 6)
[  954.367030] UBIFS error (ubi1:0 pid 756): ubifs_read_node: bad node at LEB 0:0, LEB mapping status 1
Signed-off-by: NSheng Yong <shengyong1@huawei.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

The journal update function did not work for extended attributes properly,
because extended attribute inodes carry the xattr data, and the size of this
data was not taken into account.

Artem: improved commit message, amended the patch a bit.
Signed-off-by: NSubodh Nijsure <snijsure@grid-net.com>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: NBen Shelton <ben.shelton@ni.com>
Acked-by: NBrad Mouring <brad.mouring@ni.com>
Acked-by: NGratian Crisan <gratian.crisan@ni.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

This assertion was only correct before UBIFS had xattr support.
Now with xattr support also a directory node can carry data
and can act as host node.
Suggested-by: NArtem Bityutskiy <dedekind1@gmail.com>
Signed-off-by: NRichard Weinberger <richard@nod.at>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

Cc: Artem Bityutskiy <dedekind1@gmail.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Acked-by: NSerge Hallyn <serge.hallyn@canonical.com>
Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>

We do not need this feature and to our shame it even was not working
and there was a bug found very recently.
	-- Artem Bityutskiy

Without the data type hint UBI2 (fastmap) will be easier to implement.
Signed-off-by: NRichard Weinberger <richard@nod.at>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

This commit re-names all functions which dump something from "dbg_dump_*()" to
"ubifs_dump_*()". This is done for consistency with UBI and because this way it
will be more logical once we remove the debugging sompilation option.
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

In case of errors we almost always need the stack dump - it makes no sense
to compile it out. Remove the 'dbg_dump_stack()' function completely.
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

Remove CONFIG_UBIFS_FS_XATTR configuration option and associated
UBIFS_FS_XATTR ifdefs.

Testing:
       Tested using integck while using nandsim on x86 & MX28 based
       platform with Micron MT29F2G08ABAEAH4 nand.
Signed-off-by: NSubodh Nijsure <snijsure@grid-net.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

Before commit 56e46742 we have had locking
around all printing macros and we could use static buffers for creating
key strings and printing them. However, now we do not have that locking and
we cannot use static buffers. This commit removes the old DBGKEY() macros
and introduces few new helper macros for printing debugging messages plus
a key at the end. Thankfully, all the messages are already structures in
a way that the key is printed in the end.
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

UBIFS leaks memory on error path in 'ubifs_jnl_update()' in case of write
failure because it forgets to free the 'struct ubifs_dent_node *dent' object.
Although the object is small, the alignment can make it large - e.g., 2KiB
if the min. I/O unit is 2KiB.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
Cc: stable@kernel.org

Currently when UBIFS fills up the current bud (which is the last in the journal
head) and switches to the next bud, it first writes the log reference node for
the next bud and only after this synchronizes the write-buffer of the previous
bud. This is not a big deal, but an unclean power cut may lead to a situation
when we have corruption in a next-to-last bud, although it is much more logical
that we have to have corruption only in the last bud.

This patch also removes write-buffer synchronization from
'ubifs_wbuf_seek_nolock()' because this is not needed anymore (we synchronize
the write-buffer explicitly everywhere now) and also because this is just
prone to various errors.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

This patch improves the 'dbg_check_space_info()' function which checks
whether the amount of space before re-mounting and after re-mounting
is the same (remounting from R/O to R/W modes and vice-versa).

The problem is that 'dbg_check_space_info()' does not save the budgeting
information before re-mounting, so when an error is reported, we do not
know why the amount of free space changed.

This patches makes the following changes:

1. Teaches 'dbg_dump_budg()' function to accept a 'struct ubifs_budg_info'
   argument and print out the this argument. This way we may ask it to
   print any saved budgeting info, no only the current one.
2. Accordingly changes all the callers of 'dbg_dump_budg()' to comply with
   the changed interface.
3. Introduce a 'saved_bi' (saved budgeting info) field to
   'struct ubifs_debug_info' and save the budgeting info before re-mounting
   there.
4. Change 'dbg_check_space_info()' and make it print both old and new
   budgeting information.
5. Additionally, save 'c->igx_gc_cnt' and print it if and error happens. This
   value contributes to the amount of free space, so we have to print it.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

The current 'dbg_dump_budg()' calling convention is that the
'c->space_lock' spinlock is held. However, none of the callers
actually use it from contects which have 'c->space_lock' locked,
so all callers have to explicitely lock and unlock the spinlock.
This is not very sensible convention. This patch changes it and
makes 'dbg_dump_budg()' lock the spinlock instead of imposing this
to the callers. This simplifies the code a little.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

Running kernel 2.6.37, my PPC-based device occasionally gets an
order-2 allocation failure in UBIFS, which causes the root FS to
become unwritable:

kswapd0: page allocation failure. order:2, mode:0x4050
Call Trace:
[c787dc30] [c00085b8] show_stack+0x7c/0x194 (unreliable)
[c787dc70] [c0061aec] __alloc_pages_nodemask+0x4f0/0x57c
[c787dd00] [c0061b98] __get_free_pages+0x20/0x50
[c787dd10] [c00e4f88] ubifs_jnl_write_data+0x54/0x200
[c787dd50] [c00e82d4] do_writepage+0x94/0x198
[c787dd90] [c00675e4] shrink_page_list+0x40c/0x77c
[c787de40] [c0067de0] shrink_inactive_list+0x1e0/0x370
[c787de90] [c0068224] shrink_zone+0x2b4/0x2b8
[c787df00] [c0068854] kswapd+0x408/0x5d4
[c787dfb0] [c0037bcc] kthread+0x80/0x84
[c787dff0] [c000ef44] kernel_thread+0x4c/0x68

Similar problems were encountered last April by Tomasz Stanislawski:

http://patchwork.ozlabs.org/patch/50965/

This patch implements Artem's suggested fix: fall back to a
mutex-protected static buffer, allocated at mount time.  I tested it
by forcing execution down the failure path, and didn't see any ill
effects.

Artem: massaged the patch a little, improved it so that we'd not
allocate the write reserve buffer when we are in R/O mode.
Signed-off-by: NMatthew L. Creech <mlcreech@gmail.com>
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>