Richard Weinberger 3926df1fb5 ubifs: Handle re-linking of inodes correctly while recovery
commit e58725d51fa8da9133f3f1c54170aa2e43056b91 upstream.

UBIFS's recovery code strictly assumes that a deleted inode will never
come back, therefore it removes all data which belongs to that inode
as soon it faces an inode with link count 0 in the replay list.
Before O_TMPFILE this assumption was perfectly fine. With O_TMPFILE
it can lead to data loss upon a power-cut.

Consider a journal with entries like:
0: inode X (nlink = 0) /* O_TMPFILE was created */
1: data for inode X /* Someone writes to the temp file */
2: inode X (nlink = 0) /* inode was changed, xattr, chmod, … */
3: inode X (nlink = 1) /* inode was re-linked via linkat() */

Upon replay of entry #2 UBIFS will drop all data that belongs to inode X,
this will lead to an empty file after mounting.

As solution for this problem, scan the replay list for a re-link entry
before dropping data.

Fixes: 474b93704f32 ("ubifs: Implement O_TMPFILE")
Cc: stable@vger.kernel.org # 4.9-4.18
Cc: Russell Senior <russell@personaltelco.net>
Cc: Rafał Miłecki <zajec5@gmail.com>
Reported-by: Russell Senior <russell@personaltelco.net>
Reported-by: Rafał Miłecki <zajec5@gmail.com>
Tested-by: Rafał Miłecki <rafal@milecki.pl>
Signed-off-by: Richard Weinberger <richard@nod.at>
[rmilecki: update ubifs_assert() calls to compile with 4.18 and older]
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
(cherry picked from commit e58725d51fa8da9133f3f1c54170aa2e43056b91)
Signed-off-by: Sasha Levin <sashal@kernel.org>
2018-12-29 13:40:16 +01:00
..
2016-10-15 12:09:13 -07:00
2018-12-08 13:05:10 +01:00
2017-08-06 18:59:43 -07:00
2018-12-05 19:42:40 +01:00
2018-11-21 09:26:03 +01:00
2018-12-17 09:38:35 +01:00
2017-11-30 08:39:04 +00:00
2018-12-17 09:38:35 +01:00
2018-12-21 14:11:31 +01:00
2017-06-14 15:06:00 +02:00
2016-09-27 21:20:53 -04:00
2016-09-27 18:47:38 -04:00
2018-05-16 10:08:42 +02:00
2018-02-17 13:21:15 +01:00
2017-06-14 15:06:01 +02:00