From: Chao Yu <yuchao0@huawei.com>
To: Eric Biggers <ebiggers@kernel.org>, Gao Xiang <hsiangkao@gmx.com>
Cc: Jaegeuk Kim <jaegeuk@kernel.org>,
kernel-team@android.com, linux-kernel@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [f2fs-dev] [PATCH] f2fs: get parent inode when recovering pino
Date: Thu, 7 May 2020 14:30:15 +0800 [thread overview]
Message-ID: <cfba83e1-bae7-bd14-f41a-0d6e54366f37@huawei.com> (raw)
In-Reply-To: <5641613f-48e0-171c-cfd0-e799e24d8d11@huawei.com>
On 2020/5/6 14:55, Chao Yu wrote:
> On 2020/5/6 9:24, Eric Biggers wrote:
>> On Wed, May 06, 2020 at 08:14:07AM +0800, Gao Xiang wrote:
>>>>
>>>> Actually, I think this is wrong because the fsync can be done via a file
>>>> descriptor that was opened to a now-deleted link to the file.
>>>
>>> I'm still confused about this...
>>>
>>> I don't know what's wrong with this version from my limited knowledge?
>>> inode itself is locked when fsyncing, so
>>>
>>> if the fsync inode->i_nlink == 1, this inode has only one hard link
>>> (not deleted yet) and should belong to a single directory; and
>>>
>>> the only one parent directory would not go away (not deleted as well)
>>> since there are some dirents in it (not empty).
>>>
>>> Could kindly explain more so I would learn more about this scenario?
>>> Thanks a lot!
>>
>> i_nlink == 1 just means that there is one non-deleted link. There can be links
>> that have since been deleted, and file descriptors can still be open to them.
>>
>>>
>>>>
>>>> We need to find the dentry whose parent directory is still exists, i.e. the
>>>> parent directory that is counting towards 'inode->i_nlink == 1'.
>>>
>>> directory counting towards 'inode->i_nlink == 1', what's happening?
>>
>> The non-deleted link is the one counted in i_nlink.
>>
>>>
>>>>
>>>> I think d_find_alias() is what we're looking for.
>>>
>>> It may be simply dentry->d_parent (stable/positive as you said before, and it's
>>> not empty). why need to d_find_alias()?
>>
>> Because we need to get the dentry that hasn't been deleted yet, which isn't
>> necessarily the one associated with the file descriptor being fsync()'ed.
>>
>>> And what is the original problem? I could not get some clue from the original
>>> patch description (I only saw some extra igrab/iput because of some unknown
>>> reasons), it there some backtrace related to the problem?
>>
>> The problem is that i_pino gets set incorrectly. I just noticed this while
>> reviewing the code. It's not hard to reproduce, e.g.:
>>
>> #include <unistd.h>
>> #include <fcntl.h>
>> #include <sys/stat.h>
>>
>> int main()
>> {
>> int fd;
>>
>> mkdir("dir1", 0700);
>> mkdir("dir2", 0700);
>> mknod("dir1/file", S_IFREG|0600, 0);
>> link("dir1/file", "dir2/file");
>> fd = open("dir2/file", O_WRONLY);
>> unlink("dir2/file");
>> write(fd, "X", 1);
>> fsync(fd);
>> }
>>
>> Then:
>>
>> sync
>> echo N | dump.f2fs -i $(stat -c %i dir1/file) /dev/vdb | grep 'i_pino'
>> echo "dir1 (correct): $(stat -c %i dir1)"
>> echo "dir2 (wrong): $(stat -c %i dir2)"
>>
>> i_pino will point to dir2 rather than dir1 as expected.
>
> Could you add above testcase into commit message of your patch? it will
> be easier to understand the issue we solved with it.
>
> In addition, how about adding this testcase in fstest as a generic one?
Oops, it's not a generic one... please ignore this.
>
>>
>> - Eric
>>
>>
>> _______________________________________________
>> Linux-f2fs-devel mailing list
>> Linux-f2fs-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
>> .
>>
>
>
> _______________________________________________
> Linux-f2fs-devel mailing list
> Linux-f2fs-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
> .
>
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
prev parent reply other threads:[~2020-05-07 6:30 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-05 15:31 [f2fs-dev] [PATCH] f2fs: get parent inode when recovering pino Jaegeuk Kim
2020-05-05 16:58 ` Eric Biggers
2020-05-05 17:59 ` Eric Biggers
2020-05-05 18:20 ` Jaegeuk Kim
2020-05-05 18:13 ` Jaegeuk Kim
2020-05-05 18:19 ` Eric Biggers
2020-05-05 18:49 ` Jaegeuk Kim
2020-05-05 19:01 ` Eric Biggers
2020-05-05 19:08 ` Jaegeuk Kim
2020-05-06 0:14 ` Gao Xiang
2020-05-06 1:24 ` Eric Biggers
2020-05-06 1:58 ` Gao Xiang via Linux-f2fs-devel
2020-05-06 6:47 ` Gao Xiang
2020-05-06 19:16 ` Eric Biggers
2020-05-06 22:36 ` Gao Xiang
2020-05-07 6:38 ` Chao Yu
2020-05-07 7:23 ` Gao Xiang
2020-05-06 6:55 ` Chao Yu
2020-05-07 6:30 ` Chao Yu [this message]
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=cfba83e1-bae7-bd14-f41a-0d6e54366f37@huawei.com \
--to=yuchao0@huawei.com \
--cc=ebiggers@kernel.org \
--cc=hsiangkao@gmx.com \
--cc=jaegeuk@kernel.org \
--cc=kernel-team@android.com \
--cc=linux-f2fs-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).