Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1503677pxb; Fri, 22 Jan 2021 18:48:04 -0800 (PST) X-Google-Smtp-Source: ABdhPJxdWVTi7C5fjan/dK9cK500o2RrtGOKVyn8SQkoKMjoZgyG7tzU0r2xlZ42UVbfT8F4YWLQ X-Received: by 2002:a17:906:c5b:: with SMTP id t27mr5001828ejf.129.1611370084421; Fri, 22 Jan 2021 18:48:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611370084; cv=none; d=google.com; s=arc-20160816; b=bBVDV8iP7qrg4zbNrEREFVWHLIvBFNREKh2Zp+hv3SH8LXCSLGDH4SzV0+3VNxaxij rz4tFvoP89sKMzhSDVGFbllkDfVEN6tAekcaItex/3gE+oTouk8HPBc/2l3expk0/WH3 VtxHTzo6QZa8o4e6oWNKZ2s2yJ3L9AuIcQuGqWwtQsYQJPRgmEVsJtVxUGRBIqvuLdlN Anrz8RgRFDcl17D/ywcwO43E1QzGP8VQbI9Z0j7JLIL7QgUtP0AfKe9twrG5FD4lwSUd gUjxw7ap1MdFwoaHm3A4JNdt2fgQzL9+nUaC0OCSkhwWAczhkvkQJN2FMfVt+LP3u485 5Vrw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:references:cc:to :subject; bh=iIJLsfYjJhlQtXsp1RshqHRsqjvNcqgdYzAJrauwJJQ=; b=sFfXpkQxQbeqr7HZa+ot+JMHF2Ee1UBbQwQsdJoH5BC9uUiGQTUSIjhc+nhF6eX0Fv w2JOpgefTu59W/7KnB8GPvLwh3hbhsPDvhTQlh8KbMCErNRgjHdajZZRpzEQD/gvPKsH emCU6+5KNKANvcGLqb8Irtoni3QnhPDeI3ZQyYEipilJpLhMbfmwfI4j4C78FZR/WA3l se43/sJI8yUERehZTQfVN9zOO4ETs75JacqtrxWnQswK7XCc+GP1ZWBDxOeWSSOP5MbN 0np4R6MXb8xThszrRKxurDQG9SSKHvAiofOXHk/oseftQ892dlS4RYId6crrEmu6b9R2 EuZg== ARC-Authentication-Results: i=1; mx.google.com; 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 r4si3624935ejj.81.2021.01.22.18.47.40; Fri, 22 Jan 2021 18:48:04 -0800 (PST) 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; 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 S1726503AbhAWCqG (ORCPT + 99 others); Fri, 22 Jan 2021 21:46:06 -0500 Received: from szxga04-in.huawei.com ([45.249.212.190]:11182 "EHLO szxga04-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726024AbhAWCqF (ORCPT ); Fri, 22 Jan 2021 21:46:05 -0500 Received: from DGGEMS413-HUB.china.huawei.com (unknown [172.30.72.59]) by szxga04-in.huawei.com (SkyGuard) with ESMTP id 4DN0nQ0059zl7Zc; Sat, 23 Jan 2021 10:43:53 +0800 (CST) Received: from [10.174.176.185] (10.174.176.185) by DGGEMS413-HUB.china.huawei.com (10.3.19.213) with Microsoft SMTP Server id 14.3.498.0; Sat, 23 Jan 2021 10:45:16 +0800 Subject: Re: [PATCH 3/4] ubifs: Update directory size when creating whiteouts To: Richard Weinberger , CC: , , References: <20210122212229.17072-1-richard@nod.at> <20210122212229.17072-4-richard@nod.at> From: Zhihao Cheng Message-ID: <5b51ff9c-8f5e-c348-5195-c0a0bf60b746@huawei.com> Date: Sat, 23 Jan 2021 10:45:15 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <20210122212229.17072-4-richard@nod.at> Content-Type: text/plain; charset="gbk"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.176.185] X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org ?? 2021/1/23 5:22, Richard Weinberger ะด??: > Although whiteouts are unlinked files they will get re-linked later, I just want to make sure, is this where the count is increased? do_rename -> inc_nlink(whiteout) > therefore the size of the parent directory needs to be updated too. > > Cc: stable@vger.kernel.org > Fixes: 9e0a1fff8db5 ("ubifs: Implement RENAME_WHITEOUT") > Signed-off-by: Richard Weinberger > --- > fs/ubifs/dir.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/fs/ubifs/dir.c b/fs/ubifs/dir.c > index 8a34e0118ee9..b5d523e5854f 100644 > --- a/fs/ubifs/dir.c > +++ b/fs/ubifs/dir.c > @@ -361,6 +361,7 @@ static int do_tmpfile(struct inode *dir, struct dentry *dentry, > struct ubifs_budget_req ino_req = { .dirtied_ino = 1 }; > struct ubifs_inode *ui, *dir_ui = ubifs_inode(dir); > int err, instantiated = 0; > + int sz_change = 0; > struct fscrypt_name nm; > > /* > @@ -411,6 +412,8 @@ static int do_tmpfile(struct inode *dir, struct dentry *dentry, > mark_inode_dirty(inode); > drop_nlink(inode); > *whiteout = inode; > + sz_change = CALC_DENT_SIZE(fname_len(&nm)); > + dir->i_size += sz_change; > } else { > d_tmpfile(dentry, inode); > } > @@ -430,6 +433,7 @@ static int do_tmpfile(struct inode *dir, struct dentry *dentry, > return 0; > > out_cancel: Does this need a judgment? Like this, if (whiteout) dir->i_size -= sz_change; > + dir->i_size -= sz_change; > mutex_unlock(&dir_ui->ui_mutex); > out_inode: > make_bad_inode(inode); >