mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Zhihao Cheng <chengzhihao1@huawei.com>
To: Richard Weinberger <richard.weinberger@gmail.com>
Cc: <linux-mtd@lists.infradead.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Richard Weinberger <richard@nod.at>,
	"zhangyi (F)" <yi.zhang@huawei.com>
Subject: Re: [PATCH] ubifs: Fix a potential space leak problem while linking tmpfile
Date: Tue, 7 Jul 2020 19:54:57 +0800	[thread overview]
Message-ID: <082f18e0-d6f0-6389-43af-3159edb244cb@huawei.com> (raw)
In-Reply-To: <CAFLxGvyO_aXGfgoO0mrNsoGP4Bfh3n6CUQxDx=ecH6o2ZDNYDg@mail.gmail.com>

在 2020/7/7 19:26, Richard Weinberger 写道:
> On Wed, Jul 1, 2020 at 1:28 PM Zhihao Cheng <chengzhihao1@huawei.com> 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.



  reply	other threads:[~2020-07-07 11:55 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-01 11:26 Zhihao Cheng
2020-07-07 11:26 ` Richard Weinberger
2020-07-07 11:54   ` Zhihao Cheng [this message]
2020-07-07 12:09     ` Richard Weinberger
2020-07-07 12:36       ` Zhihao Cheng
2020-07-07 12:47         ` Richard Weinberger
2020-07-11  6:37           ` Zhihao Cheng
2020-07-11  6:44             ` Zhihao Cheng
2020-07-13  3:30             ` Zhihao Cheng
  -- strict thread matches above, loose matches on Subject: below --
2020-07-01  9:32 Zhihao Cheng

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=082f18e0-d6f0-6389-43af-3159edb244cb@huawei.com \
    --to=chengzhihao1@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=richard.weinberger@gmail.com \
    --cc=richard@nod.at \
    --cc=yi.zhang@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®