Received: by 2002:a25:23cc:0:0:0:0:0 with SMTP id j195csp1290461ybj; Tue, 5 May 2020 17:18:52 -0700 (PDT) X-Google-Smtp-Source: APiQypKjYvxMeqRgksfLQ4SkBPNDH+e/Wgs7IdCbWpo1ebTCme0Gk1pc1mz3IFwlWV9nNiOrh0RL X-Received: by 2002:a50:9e8f:: with SMTP id a15mr4775378edf.68.1588724331944; Tue, 05 May 2020 17:18:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588724331; cv=none; d=google.com; s=arc-20160816; b=o+cPaToxXik5Jli3qqIpFmO3B31vBU1oeVNqB4d2GGCxoELXtGs/rUySdsR9ZpmYV5 OqCy2MoWIdALReQ9rW+cMiE5EmPBQMwxag2wPRL66wDHwTg/1ZO2CTqgkxuD0aT7n93V wxO/8hSQjt0b916/+YDfp7FQlTEWguQ9BTxUJWjgFIdpL+Ptgs7BHiwBuvgCqLPwQi2Q LsSspmduA/Dzz/C2an1A40ybm5y2dQ9kfL0DOHA2g+wMT3dFMU8fzUFbjsn/N+86i5Ho Ir/xbhNrxgWUYl9kzgR3wvdSAsAs046+SwKnCVoPaFDzVugzoaojshP+fR/7YW1ZtrvA zg0A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:user-agent :in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:dkim-signature; bh=Xw0eUsDrA5vWBvK0Y3BR7p00UQdAeIHj+FGYBktA2ik=; b=uzf+InpgNS4AZ7EYnO2WxvULVjA4+oSD+l4pc3jljbHz9RlGkNP4I21RpJumW4lqLo lVnnDwgkf5gv2gFNF4qrY2haoqUckhN7jG+C3dJ7W+BhedDKzPFL8UuHxTS77t9joCsy 0w81ZLzq7m0bUcCYKtoujRt8GvUZa7m0mr9Hlzq4hyVyTSVJIMANQXYxdySIw1LBXCeM UBRHxLcLvef8XX/HH+fTedV7zVcwi7vX9gUbn83o97ZI6Thg4I1wK+gaN10Pn2+aU+gy XNRs7GtpqpKXZP7uXpeoSMTWzvwkzwA93m5X95A0N3St/HG3ImnY1xwVH4vNsLGaCHkP 3Crw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmx.net header.s=badeba3b8450 header.b=lSbwrVKn; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id bz15si136685ejc.391.2020.05.05.17.18.28; Tue, 05 May 2020 17:18:51 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmx.net header.s=badeba3b8450 header.b=lSbwrVKn; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729247AbgEFAOg (ORCPT + 99 others); Tue, 5 May 2020 20:14:36 -0400 Received: from mout.gmx.net ([212.227.17.21]:50981 "EHLO mout.gmx.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727989AbgEFAOg (ORCPT ); Tue, 5 May 2020 20:14:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1588724055; bh=VstGBM+9+BOrff1fXnmRzhytiHYZbjWPVGkVLancL10=; h=X-UI-Sender-Class:Date:From:To:Cc:Subject:References:In-Reply-To; b=lSbwrVKnFUHv6uPM8VAiWp2OJ8BAEw6EADIbyWpNmYoD5ADYCxycToszJuwEAYRgj 2eXSF7lMLJaOmWptEMpnqNVb37j4aoWs0t6+0Do8n3mlMxWBs5CYMMTtPYdYIuYR5+ q7wDeiYNIekM1uCAPAungqPVF2IFHkZxlGx9Df+c= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from hsiangkao-HP-ZHAN-66-Pro-G1 ([120.242.76.42]) by mail.gmx.com (mrgmx105 [212.227.17.174]) with ESMTPSA (Nemesis) id 1MulmF-1jESOL0V9P-00rmbp; Wed, 06 May 2020 02:14:15 +0200 Date: Wed, 6 May 2020 08:14:07 +0800 From: Gao Xiang To: Eric Biggers Cc: Jaegeuk Kim , 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 Message-ID: <20200506001403.GA2101@hsiangkao-HP-ZHAN-66-Pro-G1> References: <20200505153139.201697-1-jaegeuk@kernel.org> <20200505165847.GA98848@gmail.com> <20200505181323.GA55221@google.com> <20200505181941.GC98848@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200505181941.GC98848@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Provags-ID: V03:K1:+cT0PQODTEdyEfpz5fSWeJDDU8z3WioTeZk54M4Xhf1yjRJkS44 CMFp1mJW90JMOme4N7Mj0WXSqrczBdkbosVHWt3r5tNF80UszC0G7pD0sFloC26EmqVy12a N4jnNR6klWlwdITPteT+bdQLQ20827C9nw5JiPiWKHRYtkQ2B0Csmw+fzxXbVXp49Jlsuwe VQucEDOgzxJUWFd0dzgDA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:Zqz0WlMk7ng=:em/tm00iXuGtgmOnGNV8+C iWr7hedhiGqpfCxvCyqHti9eM5Sb0YSvic39fJIjuEkBeIJattV+az9w61ki2fkvjoDTYHkOF uNo6pXIDoby+Ky1IQjjhZWw9MN0ePUQ36xIrcZ5Z+7SfUo+m7uihhnumc21tL2WOSJDa49d35 1DG5FZRRSYSyMVCocckL3jsh5E8bDU1r1izSKoJeY6EpXowsbOQx0ws642vnNcmXaOgwJwYZt ntSQXL756qX2MUI65H46mgSuV0PtTbEChusD1k5JJwWSRi7wqK3fPcaoY25HMPj+bzpS6l8Ke CpRWrzMuyNrJ+2mJTX5XjAWkgjlGAJxTAu5anrA9X4kb91zPPcGwIsedFR+erkGW3rbfOhZtO EBl87dJEh7KEVBYp7nbIieXf4ZxH8omWUxbcG5oP0xhwvF4Sve/LWr0n/MVLpKZ76rGBvfCk7 +5q++3U/EAKGQZuTtt9qmwNpGEBnvhItbYGn6uMtrPmwZMGtOWlCIE47e9saJH+QvByKb67ZK m4znWWxVSCq+AXlSxEMfSDeHAlLuu4V37ZM8D08/QkZTkc2jWX2m8KvzfwzFxcCLH152BdiTr KUwS+f0zIfpqO0OQznD86TAXezpKL+fFzkNkmSYPP/iSurLLsj4NTLb/+RsbK4cH3y5G9k7Oe 50Nz1KRcdUclNh3Ag+sR+tNhRLuNgxIxM6SNn7MDcGHTwH8JQrU1earv1kVo7nijGRoWjmP3w ytOMEOTLUZa5Jm1SswvRiMVg2nhJopVGuZbCii5RvF0+6dXwZN3jSLVYGCymMcyo8bW7sRBNb RgQ6C4v7ENLneUiY23Ey+o4CrIqcSwxg2E84yf1AF5KPkwFlYLRTxNK0TKPTHV1XbhZXBA8pI cdcBKBS4TTkyWK8jgwE02oRlYVsWFT7lyRHqo+LPm25gT/FdpnzcxylFz2j+eAmOJImszIvaG gjF7cMA3Kf4/d5V3qT61AVYdWHhCku9gu8zdP3wUgsq2O1fTCmya1mb9vjQqtsNAJQUC0sDny l9qeRKL+6OyXNl5nCJmPzNxSvN+nxJHaUBg3q3OFFo1qt2oYR4mZaHF4dykZB521ljIsRmFhp 3nZtzRpIbShj+9uGX9Mfc82CARFS7MVP42QZ9DogVXQ1VGoMdI8pTOuNLv/+ug4joBPyPHVE9 Zx6SXU5hedTbA1gA0cDi2lc7f/VBADD66x45Bg3Mzjx7zy3XSpGCLoTT4znzHFDeJ+ZZBPCup N31N7+xcxwtjzile2 Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Eric, On Tue, May 05, 2020 at 11:19:41AM -0700, Eric Biggers wrote: > On Tue, May 05, 2020 at 11:13:23AM -0700, Jaegeuk Kim wrote: ... > > > > -static int get_parent_ino(struct inode *inode, nid_t *pino) > > -{ > > - struct dentry *dentry; > > - > > - inode =3D igrab(inode); > > - dentry =3D d_find_any_alias(inode); > > - iput(inode); > > - if (!dentry) > > - return 0; > > - > > - *pino =3D parent_ino(dentry); > > - dput(dentry); > > - return 1; > > -} > > - > > static inline enum cp_reason_type need_do_checkpoint(struct inode *in= ode) > > { > > struct f2fs_sb_info *sbi =3D F2FS_I_SB(inode); > > @@ -223,14 +208,15 @@ static bool need_inode_page_update(struct f2fs_s= b_info *sbi, nid_t ino) > > return ret; > > } > > > > -static void try_to_fix_pino(struct inode *inode) > > +static void try_to_fix_pino(struct dentry *dentry) > > { > > + struct inode *inode =3D d_inode(dentry); > > struct f2fs_inode_info *fi =3D F2FS_I(inode); > > - nid_t pino; > > > > down_write(&fi->i_sem); > > - if (file_wrong_pino(inode) && inode->i_nlink =3D=3D 1 && > > - get_parent_ino(inode, &pino)) { > > + if (file_wrong_pino(inode) && inode->i_nlink =3D=3D 1) { > > + nid_t pino =3D parent_ino(dentry); > > + > > f2fs_i_pino_write(inode, pino); > > file_got_pino(inode); > > } > > @@ -310,7 +296,7 @@ static int f2fs_do_sync_file(struct file *file, lo= ff_t start, loff_t end, > > * We've secured consistency through sync_fs. Following pino > > * will be used only for fsynced inodes after checkpoint. > > */ > > - try_to_fix_pino(inode); > > + try_to_fix_pino(file_dentry(file)); > > clear_inode_flag(inode, FI_APPEND_WRITE); > > clear_inode_flag(inode, FI_UPDATE_WRITE); > > goto out; > > 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 =3D=3D 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! > > We need to find the dentry whose parent directory is still exists, i.e. = the > parent directory that is counting towards 'inode->i_nlink =3D=3D 1'. directory counting towards 'inode->i_nlink =3D=3D 1', what's happening? > > 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()? And what is the original problem? I could not get some clue from the origi= nal patch description (I only saw some extra igrab/iput because of some unknow= n reasons), it there some backtrace related to the problem? Thanks, Gao Xiang > > diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c > index 6ab8f621a3c5..855f27468baa 100644 > --- a/fs/f2fs/file.c > +++ b/fs/f2fs/file.c > @@ -165,13 +165,13 @@ static int get_parent_ino(struct inode *inode, nid= _t *pino) > { > struct dentry *dentry; > > - inode =3D igrab(inode); > - dentry =3D d_find_any_alias(inode); > - iput(inode); > + dentry =3D d_find_alias(inode); > if (!dentry) > return 0; > > > > _______________________________________________ > Linux-f2fs-devel mailing list > Linux-f2fs-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel