linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: 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: Tue, 5 May 2020 18:24:28 -0700	[thread overview]
Message-ID: <20200506012428.GG128280@sol.localdomain> (raw)
In-Reply-To: <20200506001403.GA2101@hsiangkao-HP-ZHAN-66-Pro-G1>

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.

- Eric

  reply	other threads:[~2020-05-06  1:24 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-05 15:31 [PATCH] f2fs: get parent inode when recovering pino Jaegeuk Kim
2020-05-05 16:58 ` [f2fs-dev] " 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 [this message]
2020-05-06  1:58           ` Gao Xiang
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

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=20200506012428.GG128280@sol.localdomain \
    --to=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).