Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp51003ybl; Tue, 10 Dec 2019 17:24:25 -0800 (PST) X-Google-Smtp-Source: APXvYqzPFKfFgit0whLQN6oKXgIMwyCxEW3/8HrPXp1jeoDu+GPig3nnK3BWRwqm++VHrs1TzVcb X-Received: by 2002:a54:440d:: with SMTP id k13mr861312oiw.128.1576027465768; Tue, 10 Dec 2019 17:24:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1576027465; cv=none; d=google.com; s=arc-20160816; b=MyhoiNQGn3fwGTVsZ9I1/Lwy4B1VoAJJgEeWn1tVwdjVozgZAgdIJkpGv2B4vXE3We dDEj4IP0vjQc1/SdHQWnEsBmJbiUodPF+9AKKNjB7FPlfyKbV5O+5RPr5Q2F1lesxgli nxVgTZAGWOgBDqQOZeqMlelR1iR5GU2gbZ5RmSltoKfL3mBxmQUTOJB0b6E6BnqpMq2C j8tlu38dYomtDuGfn/ZuzWIfr6deRM7SX2EOWnq2KKaxxOJuYXXWX1WxOgL8iEBSK0R/ 1vrka1ITOGtHJlWU1UBOVh+Xglz5QCRMvvHymznt/gXijf1UEL7rrMhH41FnONfs0zZv o1rg== 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=BTpI7hrBIrWR3VuGaDkPYV0QtV65HZajqf5kO8OS+Ms=; b=lOHmkV9CvC1f0rJo2o/SvjhNZkdVxFxorn3AKN5HwYCKmnHXltSgh9yRcBMRS94NGR jlEIxmWziUEWjOXSiI8YGbUbYjI8j/1FMMVpvsiqfsdvRQmVgExBAFc0IOVklj0jQAGh Y+6ztlkqpomVX776EST5jp6OTOb5K7+poYIpVkpt1zzDdh3KxDmKNGNowArnIsYy5gaM gavyWM0qLnRFxAGpI0TLa++CT5q1W7b6VS/XDGqdQs9A4Yk1HKBkXBAe9YcCgfuj3QoC SLRaVHs8CWEtQ6e5ZCRs69WtclC34w++hlERS97+3tBG2GY1FBt69+wq7UOjcmQYJV13 z3tA== 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 h8si113641otk.183.2019.12.10.17.24.12; Tue, 10 Dec 2019 17:24:25 -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 S1726619AbfLKBXl (ORCPT + 99 others); Tue, 10 Dec 2019 20:23:41 -0500 Received: from szxga05-in.huawei.com ([45.249.212.191]:7209 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726364AbfLKBXl (ORCPT ); Tue, 10 Dec 2019 20:23:41 -0500 Received: from DGGEMS412-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id 406D7A3183CC6694E5BE; Wed, 11 Dec 2019 09:23:39 +0800 (CST) Received: from [10.134.22.195] (10.134.22.195) by smtp.huawei.com (10.3.19.212) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 11 Dec 2019 09:23:34 +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> From: Chao Yu Message-ID: <00ced682-9522-236d-4078-4c8f2e348d39@huawei.com> Date: Wed, 11 Dec 2019 09:23:34 +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: <20191211012121.GA52962@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: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? 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; >>> } >>> >>> > . >