Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp64718ybl; Tue, 10 Dec 2019 17:43:00 -0800 (PST) X-Google-Smtp-Source: APXvYqxX6LL/n6BPWmSOvld2Wt6Qua6AOAavqe4xs1GfCjC2zh9XUbYPjm716X78n7JjkR75Mmso X-Received: by 2002:a54:4518:: with SMTP id l24mr826121oil.41.1576028580678; Tue, 10 Dec 2019 17:43:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1576028580; cv=none; d=google.com; s=arc-20160816; b=i4wyVptBxQmYhxCaHoAD0Neaf21icVXSg/aEVBl093rl3OhfuxsKYjhBiYMlz2tuA0 J5RJZrHv14iFDwl/V/ege/ud38GIy27pURbcqh7JRiqDyY/Jn/JqklBcwFEVKHMl4iIb YWOodO/EYQCH1r4FDIYuaw/QfeBBMr1yaNtxzBL432yveAhqeGw9kH0Ass31Xe8PfDpa 7l/7LKadq6a5ES8zixKtffmXO7zqC/4+HnZHWUkJSx31zy7aFtVApyqyR1ZdjMnM20/9 pxqqUBhtHgDTfENFSfUj3Nsvplhh9Gtg1YBI+kHnMIt3P19PS9kMOEBgHJoRbhpqWlz1 svfA== 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 :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=3YkFOPfC9ZPn4bHmSnr4ZXE3klr8U/RVlI0Vnj/L6Ew=; b=LfO1JxNI9i0YG+Ctwyz5sqJsqlTYTY4uUzbR4xenkKeWx1aMMB67otgDj8lvuZRVAm Sxwsx0DOlbfDTqI+aQ7JlVP3af6lOD3av9cyBFnXRM/+2JNq2vKsztBilEpeOgpyBW5h YMcR40f1efh9e7yLglImR4tSigBuWbDLY0gpJCIElDMvr3Zyq8yVZJP1KoBqTybMRuVY t4p/xvLBlcR/JRktDbQP0zk/JPlDaav3bk+ij7FgWy0OwbPLohwdYNYmTWGQBBKT0xG+ BOGh+SQF1gN9B5qTovh7mRa/N/Jg+WDMrhUUUsxrnLLsI67cp2XK+WbJRFsrLYEmFhJH StXQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m19si226977oig.91.2019.12.10.17.42.48; Tue, 10 Dec 2019 17:43:00 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727119AbfLKBmH (ORCPT + 99 others); Tue, 10 Dec 2019 20:42:07 -0500 Received: from szxga07-in.huawei.com ([45.249.212.35]:37168 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726417AbfLKBmG (ORCPT ); Tue, 10 Dec 2019 20:42:06 -0500 Received: from DGGEMS413-HUB.china.huawei.com (unknown [172.30.72.59]) by Forcepoint Email with ESMTP id D323C4F4F6E34CA96FF6; Wed, 11 Dec 2019 09:42:03 +0800 (CST) Received: from [10.134.22.195] (10.134.22.195) by smtp.huawei.com (10.3.19.213) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 11 Dec 2019 09:42:01 +0800 Subject: Re: [f2fs-dev] [PATCH 6/6] f2fs: set I_LINKABLE early to avoid wrong access by vfs To: Jaegeuk Kim CC: , References: <20191209222345.1078-1-jaegeuk@kernel.org> <20191209222345.1078-6-jaegeuk@kernel.org> <88dcbca9-3757-a440-ed73-9d99a56b816c@huawei.com> <20191211012121.GA52962@jaegeuk-macbookpro.roam.corp.google.com> <00ced682-9522-236d-4078-4c8f2e348d39@huawei.com> <20191211013124.GB57416@jaegeuk-macbookpro.roam.corp.google.com> From: Chao Yu Message-ID: Date: Wed, 11 Dec 2019 09:42:04 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20191211013124.GB57416@jaegeuk-macbookpro.roam.corp.google.com> Content-Type: text/plain; charset="windows-1252" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.134.22.195] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2019/12/11 9:31, Jaegeuk Kim wrote: > On 12/11, Chao Yu wrote: >> On 2019/12/11 9:21, Jaegeuk Kim wrote: >>> On 12/10, Chao Yu wrote: >>>> On 2019/12/10 6:23, Jaegeuk Kim wrote: >>>>> This patch moves setting I_LINKABLE early in rename2(whiteout) to avoid the >>>>> below warning. >>>>> >>>>> [ 3189.163385] WARNING: CPU: 3 PID: 59523 at fs/inode.c:358 inc_nlink+0x32/0x40 >>>>> [ 3189.246979] Call Trace: >>>>> [ 3189.248707] f2fs_init_inode_metadata+0x2d6/0x440 [f2fs] >>>>> [ 3189.251399] f2fs_add_inline_entry+0x162/0x8c0 [f2fs] >>>>> [ 3189.254010] f2fs_add_dentry+0x69/0xe0 [f2fs] >>>>> [ 3189.256353] f2fs_do_add_link+0xc5/0x100 [f2fs] >>>>> [ 3189.258774] f2fs_rename2+0xabf/0x1010 [f2fs] >>>>> [ 3189.261079] vfs_rename+0x3f8/0xaa0 >>>>> [ 3189.263056] ? tomoyo_path_rename+0x44/0x60 >>>>> [ 3189.265283] ? do_renameat2+0x49b/0x550 >>>>> [ 3189.267324] do_renameat2+0x49b/0x550 >>>>> [ 3189.269316] __x64_sys_renameat2+0x20/0x30 >>>>> [ 3189.271441] do_syscall_64+0x5a/0x230 >>>>> [ 3189.273410] entry_SYSCALL_64_after_hwframe+0x49/0xbe >>>>> [ 3189.275848] RIP: 0033:0x7f270b4d9a49 >>>>> >>>>> Signed-off-by: Jaegeuk Kim >>>>> --- >>>>> fs/f2fs/namei.c | 27 +++++++++++++-------------- >>>>> 1 file changed, 13 insertions(+), 14 deletions(-) >>>>> >>>>> diff --git a/fs/f2fs/namei.c b/fs/f2fs/namei.c >>>>> index a1c507b0b4ac..5d9584281935 100644 >>>>> --- a/fs/f2fs/namei.c >>>>> +++ b/fs/f2fs/namei.c >>>>> @@ -797,6 +797,7 @@ static int __f2fs_tmpfile(struct inode *dir, struct dentry *dentry, >>>>> >>>>> if (whiteout) { >>>>> f2fs_i_links_write(inode, false); >>>>> + inode->i_state |= I_LINKABLE; >>>>> *whiteout = inode; >>>>> } else { >>>>> d_tmpfile(dentry, inode); >>>>> @@ -867,6 +868,12 @@ static int f2fs_rename(struct inode *old_dir, struct dentry *old_dentry, >>>>> F2FS_I(old_dentry->d_inode)->i_projid))) >>>>> return -EXDEV; >>>>> >>>>> + if (flags & RENAME_WHITEOUT) { >>>>> + err = f2fs_create_whiteout(old_dir, &whiteout); >>>>> + if (err) >>>>> + return err; >>>>> + } >>>> >>>> To record quota info correctly, we need to create whiteout inode after >>>> dquot_initialize(old_dir)? >>> >>> __f2fs_tmpfile() will do it. >> >> Okay. >> >> Any comments on below question? >> >>> >>>> >>>>> + >>>>> err = dquot_initialize(old_dir); >>>>> if (err) >>>>> goto out; >>>>> @@ -898,17 +905,11 @@ static int f2fs_rename(struct inode *old_dir, struct dentry *old_dentry, >>>>> } >>>>> } >>>>> >>>>> - if (flags & RENAME_WHITEOUT) { >>>>> - err = f2fs_create_whiteout(old_dir, &whiteout); >>>>> - if (err) >>>>> - goto out_dir; >>>>> - } >>>>> - >>>>> if (new_inode) { >>>>> >>>>> err = -ENOTEMPTY; >>>>> if (old_dir_entry && !f2fs_empty_dir(new_inode)) >>>>> - goto out_whiteout; >>>>> + goto out_dir; >>>>> >>>>> err = -ENOENT; >>>>> new_entry = f2fs_find_entry(new_dir, &new_dentry->d_name, >>>>> @@ -916,7 +917,7 @@ static int f2fs_rename(struct inode *old_dir, struct dentry *old_dentry, >>>>> if (!new_entry) { >>>>> if (IS_ERR(new_page)) >>>>> err = PTR_ERR(new_page); >>>>> - goto out_whiteout; >>>>> + goto out_dir; >>>>> } >>>>> >>>>> f2fs_balance_fs(sbi, true); >>>>> @@ -948,7 +949,7 @@ static int f2fs_rename(struct inode *old_dir, struct dentry *old_dentry, >>>>> err = f2fs_add_link(new_dentry, old_inode); >>>>> if (err) { >>>>> f2fs_unlock_op(sbi); >>>>> - goto out_whiteout; >>>>> + goto out_dir; >>>>> } >>>>> >>>>> if (old_dir_entry) >>>>> @@ -972,7 +973,7 @@ static int f2fs_rename(struct inode *old_dir, struct dentry *old_dentry, >>>>> if (IS_ERR(old_page)) >>>>> err = PTR_ERR(old_page); >>>>> f2fs_unlock_op(sbi); >>>>> - goto out_whiteout; >>>>> + goto out_dir; >>>>> } >>>>> } >>>>> } >>>>> @@ -991,7 +992,6 @@ static int f2fs_rename(struct inode *old_dir, struct dentry *old_dentry, >>>>> f2fs_delete_entry(old_entry, old_page, old_dir, NULL); >>>>> >>>>> if (whiteout) { >>>>> - whiteout->i_state |= I_LINKABLE; >>>>> set_inode_flag(whiteout, FI_INC_LINK); >>>>> err = f2fs_add_link(old_dentry, whiteout); >>>> >>>> [ 3189.256353] f2fs_do_add_link+0xc5/0x100 [f2fs] >>>> [ 3189.258774] f2fs_rename2+0xabf/0x1010 [f2fs] >>>> >>>> Does the call stack point here? if so, we have set I_LINKABLE before >>>> f2fs_add_link(), why the warning still be triggered? >> >> Am I missing something? > > Not sure exactly tho, I suspect some races before/after unlock_new_inode(). Alright, I doubt some races on whiteout->i_state updating, as we set I_LINKABLE w/o holding inode.i_lock. Could you have a try with holding i_lock? Thanks, > >> >> Thanks, >> >>>> >>>> Thanks, >>>> >>>>> if (err) >>>>> @@ -1027,15 +1027,14 @@ static int f2fs_rename(struct inode *old_dir, struct dentry *old_dentry, >>>>> f2fs_unlock_op(sbi); >>>>> if (new_page) >>>>> f2fs_put_page(new_page, 0); >>>>> -out_whiteout: >>>>> - if (whiteout) >>>>> - iput(whiteout); >>>>> out_dir: >>>>> if (old_dir_entry) >>>>> f2fs_put_page(old_dir_page, 0); >>>>> out_old: >>>>> f2fs_put_page(old_page, 0); >>>>> out: >>>>> + if (whiteout) >>>>> + iput(whiteout); >>>>> return err; >>>>> } >>>>> >>>>> >>> . >>> > . >