Re: [PATCH] ubifs: Fix a potential space leak problem while linking tmpfile

From: Zhihao Cheng
Date: Tue Jul 07 2020 - 07:55:09 EST


å 2020/7/7 19:26, Richard Weinberger åé:
On Wed, Jul 1, 2020 at 1:28 PM Zhihao Cheng <chengzhihao1@xxxxxxxxxx> wrote:
There is a potential space leak problem while linking tmpfile, in which
case, inode node (with nlink=0) is valid in tnc (on flash), which leads
to space leak. Meanwhile, the corresponding data nodes won't be released
from tnc. For example, (A reproducer can be found in Link):

$ mount UBIFS
[process A] [process B] [TNC] [orphan area]

ubifs_tmpfile inode_A (nlink=0) inode_A
do_commit inode_A (nlink=0) inode_A
â
(comment: It makes sure not replay inode_A in next mount)
ubifs_link inode_A (nlink=0) inode_A
ubifs_delete_orphan inode_A (nlink=0)
do_commit inode_A (nlink=0)
---> POWERCUT <---
(ubifs_jnl_update)

$ mount UBIFS
inode_A will neither be replayed in ubifs_replay_journal() nor
ubifs_mount_orphans(). inode_A (nlink=0) with its data nodes will
always on tnc, it occupy space but is non-visable for users.

Commit ee1438ce5dc4d ("ubifs: Check link count of inodes when killing
orphans.") handles problem in mistakenly deleting relinked tmpfile
while replaying orphan area. Since that, tmpfile inode should always
live in orphan area even it is linked. Fix it by reverting commit
32fe905c17f001 ("ubifs: Fix O_TMPFILE corner case in ubifs_link()").
Well, by reverting this commit you re-introduce the issue it fixes. ;-\

Perhaps I misunderstood what commit 32fe905c17f001 ("ubifs: Fix O_TMPFILE corner case in ubifs_link()") wanted to fix.
I think orphan area is used to remind filesystem don't forget to delete inodes (whose nlink is 0) in next unclean rebooting. Generally, the file system is not corrupted caused by replaying orphan nodes.
Ralph reported a filesystem corruption in combination with overlayfs. Can you tell me the details about that problem? Thanks.