Received: by 2002:a05:6500:1b8f:b0:1fa:5c73:8e2d with SMTP id df15csp360033lqb; Tue, 28 May 2024 19:10:13 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCWIgEefaJO2cPOCyddsGPub5Ahw3Mgp+UHkfVQlRzhh/q8K1oRt5NBV1tBCYc0Bdt1yFTXZrj4q87x/TuNjgj5pX/E9i7238opwpa6hAw== X-Google-Smtp-Source: AGHT+IG2QeGUmww0HjHhHxl++mGmz3UjtGY3FIIc2tKDXEIciNECnyS9goMuB6Xpgev2lBa9o/Vn X-Received: by 2002:a17:907:9482:b0:a62:cef2:5711 with SMTP id a640c23a62f3a-a62cef258damr701830466b.6.1716948613010; Tue, 28 May 2024 19:10:13 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1716948613; cv=pass; d=google.com; s=arc-20160816; b=tpL6CokT/gehDKOtaYKF6oTL3O/0E08PN3NcsFw/N5nGCKZdi4/HQAf1QrQ8azSv07 5Pb1pIXOZVYJeJXfmyoEN6yyIlodCeSgkwLIQaMniOYMtKoyPzO7Xt3TdrqqgcdBEA3/ CJkWa1Wvo7xDtBKhA5kevaP061KZaiaCNFwulCLmF2RrZwAYo3amNs8PXjzgLvvtou1K DqQRdT11SWVu30IpLQYbC/jBz1/j3YUnX6mv+PYYn9DL9Na2r7O8LLi1aWxZBj32kIAh xUYdHRiqw7coL/La3bfsWWX/7FhP+JFkplH3Mb3KYoEd7i8Xg7/VQHjhp6dHzTAYwTFS FFrg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from; bh=1BUKe6lAPbUWF42ZQ6KBz0tVSSGEJXF2g1QGOO6agIc=; fh=pGQcdj9ofLeqSf09jKNKJQluDhfJR8D6kVh7BClADBY=; b=Tzf8KHHAQg/syfTqS1bNYGv306SbYVTqlRqsPZQUj+o7QimnNJxqSptKQrxlXC80zf stx/6bhs6RRoz18MtmCZ5s/zGtxCTURX0dbKV2v+WgEqVeM4P/FYA/5VZoPkxHZZQDjn ah4XKHrBDfUfD/p9Unqr6ZwrV6ijQA0qn7rDVbA1taH771wlplM11hlRZSt0rf6B4kCP mG/9RABEEaSI1Q3z+kcTQijMLwIns+wbxFIWPbyfzIn/7v6fdWH6apApg+CAgQcrVYqx dnL+hofb6TGEknZ4t3QUyrFyvijzZB6qKw7JfZCSNjiLaLQf0iLR4UDqEmvZGL1YshXb 0wDw==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1 spf=pass spfdomain=huaweicloud.com); spf=pass (google.com: domain of linux-kernel+bounces-193313-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-193313-linux.lists.archive=gmail.com@vger.kernel.org" Return-Path: Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [2604:1380:4601:e00::3]) by mx.google.com with ESMTPS id a640c23a62f3a-a626cc68ed8si577095666b.675.2024.05.28.19.10.12 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 May 2024 19:10:12 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-193313-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3; Authentication-Results: mx.google.com; arc=pass (i=1 spf=pass spfdomain=huaweicloud.com); spf=pass (google.com: domain of linux-kernel+bounces-193313-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-193313-linux.lists.archive=gmail.com@vger.kernel.org" Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id CFD0C1F285A1 for ; Wed, 29 May 2024 01:59:42 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id B62E715ADBB; Wed, 29 May 2024 01:59:23 +0000 (UTC) Received: from dggsgout12.his.huawei.com (unknown [45.249.212.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BD81715AAD1; Wed, 29 May 2024 01:59:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.249.212.56 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1716947963; cv=none; b=dWWgj0Aeftuj9p2YwQ++NyNgyHvg6kNhjZvQZEhzZVuDGCOveZWZrNazQ9ZO7iRnRf0Ji7nv0pIsruzBYo/ymgTFHSlnOgq/KiIQEBp+pMXbBLq67xvmohcGbydwFxopVTffJLX8rgqelY/MHETOxE07TYXMhnQksWx639RoGgk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1716947963; c=relaxed/simple; bh=EftrWlTdXrV8eries2uVwbxcta6q8kmV/CnKImnKnAY=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=gczpBbgaUwPV4/RkfGd9Gu8GaTMqSFSuV5dNu7/CBeXGyVJURziatCmtScfbTG9r/ukwR0PzB14yJO1ytZ99Q8oLCXtFRikqYm0jjeMh8RkGVoxfw4ted/GDAXjbdEkzicUDp6DglUnu/TgmTF8WBpiMmd1Ojb0JbCyqS8O/4Vg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com; spf=pass smtp.mailfrom=huaweicloud.com; arc=none smtp.client-ip=45.249.212.56 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huaweicloud.com Received: from mail.maildlp.com (unknown [172.19.163.235]) by dggsgout12.his.huawei.com (SkyGuard) with ESMTP id 4Vpsxl51PTz4f3jcp; Wed, 29 May 2024 09:59:07 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.112]) by mail.maildlp.com (Postfix) with ESMTP id F21CE1A0572; Wed, 29 May 2024 09:59:16 +0800 (CST) Received: from huaweicloud.com (unknown [10.175.104.67]) by APP1 (Coremail) with SMTP id cCh0CgAn9g7wi1Zmr3XbNw--.12147S4; Wed, 29 May 2024 09:59:14 +0800 (CST) From: Zhang Yi To: linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org Cc: linux-kernel@vger.kernel.org, djwong@kernel.org, hch@infradead.org, brauner@kernel.org, david@fromorbit.com, chandanbabu@kernel.org, jack@suse.cz, willy@infradead.org, yi.zhang@huawei.com, yi.zhang@huaweicloud.com, chengzhihao1@huawei.com, yukuai3@huawei.com Subject: [RFC PATCH v4 0/8] iomap/xfs: fix stale data exposure when truncating realtime inodes Date: Wed, 29 May 2024 17:51:58 +0800 Message-Id: <20240529095206.2568162-1-yi.zhang@huaweicloud.com> X-Mailer: git-send-email 2.39.2 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-CM-TRANSID:cCh0CgAn9g7wi1Zmr3XbNw--.12147S4 X-Coremail-Antispam: 1UD129KBjvJXoWxCr17JFyfuw1UCw1Utw4ktFb_yoW5Xw1UpF Z3G3yY9r4kJ343ZFyfZ3ZFqw15u3ZYkF4UCFy7Grsak3W3Wr1Iyr1aqF45XayjkrWkWr4Y vr45tFW8urnYyFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUU9a14x267AKxVW8JVW5JwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2jI8I6cxK62vIxIIY0VWUZVW8XwA2ocxC64kIII 0Yj41l84x0c7CEw4AK67xGY2AK021l84ACjcxK6xIIjxv20xvE14v26w1j6s0DM28EF7xv wVC0I7IYx2IY6xkF7I0E14v26F4UJVW0owA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7 xvwVC2z280aVCY1x0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40E FcxC0VAKzVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWUXVWUAwAv7VC2z280aVAFwI0_Jr 0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcxkI7VAKI48JM4x0x7Aq67IIx4CEVc8v x2IErcIFxwACI402YVCY1x02628vn2kIc2xKxwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4 IE7xkEbVWUJVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1r MI8E67AF67kF1VAFwI0_Jw0_GFylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJV WUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Gr0_Cr1lIxAIcVCF04k26cxKx2IYs7xG6rW3 Jr0E3s1lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVW8JVW8Jr UvcSsGvfC2KfnxnUUI43ZEXa7sRiRwZDUUUUU== X-CM-SenderInfo: d1lo6xhdqjqx5xdzvxpfor3voofrz/ From: Zhang Yi Changes since v3: - Factor out a new helper to get the remainder in math64.h as Darrick suggested. - Adjust the truncating order to prevent too much redundant blocking writes as Dave suggested. - Improve to convert the tail extent to unwritten when truncating down an inode with large rtextsize as Darrick and Dave suggested. This series fix a stale data exposure issue reported by Chandan when running fstests generic/561 on xfs with realtime device[1]. The real problem is xfs_setattr_size() doesn't zero out enough range when truncating a realtime inode, please see the patch 6 or [1] for details. Patch 1 is from Dave, it improves truncate down performace by changing iomap_zero_iter() to aware dirty pages on unwritten extents, but for the case of the zeroing range that contains a cow mapping over a hole still needs to be handled. Patch 3-5 modify iomap_truncate_page() and dax_truncate_page() to pass filesystem identified blocksize, and drop the assumption of i_blocksize() as Dave suggested. Patch 6-7 adjust the truncating down processing order to first zero out the tail aligned blocks, then write back, update i_size and finally drop cache beyond aligned EOF. Fix the data exposure issue by zeroing out the entire EOF extent. Patch 8-9 add a rtextsize threshold (64k), improves truncate down performace on realtime inode with large rtextsize (beyonds this threshold) by converting the tail unaligned extent to unwritten. I've tested this series on fstests (1) with reflink=0, (2) with 28K RT device and (3) with 96K RT device (beyonds rtextsize threshold), no new failures detected. This series still needs to do furtuer tests with reflink=1 after Patch 1 covers the cow mapping over a hole case. [1] https://lore.kernel.org/linux-xfs/87ttj8ircu.fsf@debian-BULLSEYE-live-builder-AMD64/ Thanks, Yi. Dave Chinner (1): iomap: zeroing needs to be pagecache aware Zhang Yi (7): math64: add rem_u64() to just return the remainder iomap: pass blocksize to iomap_truncate_page() fsdax: pass blocksize to dax_truncate_page() xfs: refactor the truncating order xfs: correct the truncate blocksize of realtime inode xfs: reserve blocks for truncating realtime inode xfs: improve truncate on a realtime inode with huge extsize fs/dax.c | 8 +-- fs/ext2/inode.c | 4 +- fs/iomap/buffered-io.c | 50 ++++++++++++++-- fs/xfs/xfs_inode.c | 3 + fs/xfs/xfs_inode.h | 12 ++++ fs/xfs/xfs_iomap.c | 5 +- fs/xfs/xfs_iomap.h | 3 +- fs/xfs/xfs_iops.c | 133 +++++++++++++++++++++++++---------------- include/linux/dax.h | 4 +- include/linux/iomap.h | 4 +- include/linux/math64.h | 24 ++++++++ 11 files changed, 179 insertions(+), 71 deletions(-) -- 2.39.2