Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp952898pxp; Wed, 16 Mar 2022 22:28:17 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwtwJW5jKAfjiryvgmFGuEOcg2cO7SNYLATILbn8GICI/1gRaavm9X2BJHESkNVJSX8p8ER X-Received: by 2002:a17:903:228f:b0:151:8379:9438 with SMTP id b15-20020a170903228f00b0015183799438mr2911686plh.51.1647494897137; Wed, 16 Mar 2022 22:28:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1647494897; cv=none; d=google.com; s=arc-20160816; b=yySTZX96Keop/jD8ZXKuAbNIRZBDhz/NlT8R5FHsLljumlwhd41ZstGXR6gDlERX4w /YWkUgNgRv1JlhK603JfASql2T1w2Y3mDnWWpT3CGg6ZsdXIe6s+8OPkALnVNYiywUbS 1jCW9AbxHnCb1668aH+uZZjLlTbS0h7PP2qKnb6sxcOoOTElvqQjmXarKd4TBFcoYTmA uuw7GN3BVQEsk+m+rVmXJVFJi+GiapiLe+7cpISZGr0tetE+xkLjpgRRDneQrzaeqkEU 45OheRJZNKSBeJlJqTmEDNviUt2I86cyiwB2kM1lxtn59yc8uO5HMr9Uix/pq0pyemcV 9XnQ== 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=aczfvj/s7pvI9c1ibHDXICsr8o/Fd73XTZE1y9dYf4M=; b=VCFY1g0N4A8wR6XeAME2wdiGOFMdjwB72K7+RwPjBwZ76nMqKl3bDem1nW6cIIzYom SBiVJ0nXngNDIOrYeg5qeiBgGO2bgJYGGzR+RryQhlZPcW9hvpK9QXXYV6wyisB5PdUq q1Put8sHmt5XbYjdtYPwgbZuh37QFta1n/LS6MJqfrL5Lak8ux1E5jUJGvWY3a50i3Ps CiGjuo0EplAd6UlHKclxYzDxMmJNlQmw43czzwQ6pd9Nd0BXJra89aFiD03+AsgPnh6Y 6jMwti3QJ21R99lZUZSXOlrSpuYDXemnwX2v2S9kMPOjGsYRERQc4lzUFfN43x8DnbuA 9h/g== ARC-Authentication-Results: i=1; mx.google.com; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id u13-20020a170903124d00b00151da6b5fd8si4484222plh.275.2022.03.16.22.28.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Mar 2022 22:28:17 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id D36FC22476B; Wed, 16 Mar 2022 21:29:36 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1357321AbiCQCdS (ORCPT + 99 others); Wed, 16 Mar 2022 22:33:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44682 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1354709AbiCQCdQ (ORCPT ); Wed, 16 Mar 2022 22:33:16 -0400 Received: from szxga08-in.huawei.com (szxga08-in.huawei.com [45.249.212.255]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 64A6E1FA59 for ; Wed, 16 Mar 2022 19:31:59 -0700 (PDT) Received: from dggpeml500020.china.huawei.com (unknown [172.30.72.54]) by szxga08-in.huawei.com (SkyGuard) with ESMTP id 4KJrcy5kKLz1GCND; Thu, 17 Mar 2022 10:26:58 +0800 (CST) Received: from [10.174.177.174] (10.174.177.174) by dggpeml500020.china.huawei.com (7.185.36.88) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Thu, 17 Mar 2022 10:31:57 +0800 Subject: Re: [PATCH -next] ubifs: rename_whiteout: correct old_dir size computing To: Richard Weinberger CC: linux-mtd , linux-kernel , yukuai3 , chengzhihao1 , Baokun Li References: <20220215040736.2839939-1-libaokun1@huawei.com> <157336576.152785.1647468012272.JavaMail.zimbra@nod.at> From: "libaokun (A)" Message-ID: Date: Thu, 17 Mar 2022 10:31:57 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: <157336576.152785.1647468012272.JavaMail.zimbra@nod.at> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.177.174] X-ClientProxiedBy: dggems704-chm.china.huawei.com (10.3.19.181) To dggpeml500020.china.huawei.com (7.185.36.88) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 在 2022/3/17 6:00, Richard Weinberger 写道: > ----- Ursprüngliche Mail ----- >> Von: "libaokun" >> An: "richard" , "linux-mtd" , "linux-kernel" >> >> CC: "yukuai3" , "chengzhihao1" , "libaokun" >> Gesendet: Donnerstag, 10. März 2022 09:32:57 >> Betreff: Re: [PATCH -next] ubifs: rename_whiteout: correct old_dir size computing >> A gentle ping, sorry for the noise. > I have to say sorry for the day. > Thanks for your patience with me. > Please don't feel bad about it. Glad to hear from you! Thanks for your kindly reply! >> 在 2022/2/15 12:07, Baokun Li 写道: >>> When renaming the whiteout file, the old whiteout file is not deleted. >>> Therefore, we add the old dentry size to the old dir like XFS. >>> Otherwise, an error may be reported due to `fscki->calc_sz != fscki->size` >>> in check_indes. >>> >>> Fixes: 9e0a1fff8db56ea ("ubifs: Implement RENAME_WHITEOUT") >>> Reported-by: Zhihao Cheng >>> Signed-off-by: Baokun Li >>> --- >>> fs/ubifs/dir.c | 3 +++ >>> 1 file changed, 3 insertions(+) >>> >>> diff --git a/fs/ubifs/dir.c b/fs/ubifs/dir.c >>> index ae082a0be2a3..86151889548e 100644 >>> --- a/fs/ubifs/dir.c >>> +++ b/fs/ubifs/dir.c >>> @@ -1402,6 +1402,9 @@ static int do_rename(struct inode *old_dir, struct dentry >>> *old_dentry, >>> iput(whiteout); >>> goto out_release; >>> } >>> + >>> + /* Add the old_dentry size to the old_dir size. */ >>> + old_sz -= CALC_DENT_SIZE(fname_len(&old_nm)); > So you basically reset old_sz back to 0? Yes, reset old_sz to 0 here. Since the old file remains in old_dir after whiteout_rename, nothing has changed, we just add new_sz to the new folder. Here, old_sz is the value to be subtracted from old_dir->i_size, which is initialized to `CALC_DENT_SIZE(fname_len(&old_nm));` . In RENAME_WHITEOUT, because the old file is not deleted, we need to subtract old_dent_size from old_sz after RENAME_WHITEOUT is complete, that is, set old_sz to 0. we can easily reproduce this problem with the following script:  ```C // test_ubifs_whiteout.c  #include  #include  #include  #include  #include  int main(int argc, char *argv[])  {      system("touch /root/temp/file");      syscall(SYS_renameat2, AT_FDCWD, "/root/temp/file", AT_FDCWD, "/root/temp/target", RENAME_WHITEOUT);      return 0;  }  ``` ```shell #!/bin/bash set -e # ubifs_whiteout_reproducer.sh TMP=/root/temp umount $TMP 2>/dev/null || true mkdir -p $TMP modprobe -r ubifs 2>/dev/null || true for i in $(seq 0 1) do     ubidetach -p /dev/mtd$i 2>/dev/null || true done modprobe -r ubi 2>/dev/null || true modprobe -r nandsim 2>/dev/null || true modprobe nandsim id_bytes="0xec,0xa1,0x00,0x15" modprobe ubi mtd="0,512" ubimkvol -N vol_a -m -n 0 /dev/ubi0 modprobe ubifs mount -t ubifs /dev/ubi0_0 $TMP ./test_ubifs_whiteout umount /dev/ubi0_0 echo 1 > /sys/kernel/debug/ubifs/chk_fs mount -t ubifs /dev/ubi0_0 $TMP ``` > Thanks, > //richard > . -- With Best Regards, Baokun Li