From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C7302C282CB for ; Mon, 4 Feb 2019 16:54:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9AE5E20815 for ; Mon, 4 Feb 2019 16:54:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1549299281; bh=7KNjaSuHH+NN+pp1Du29mzGZ1DulgXtmyY4eA6tMomo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=vXKfKu0SrWCTIlzLFVBCAe+8XwJLBi06YH5MzJXK9+AGaD5uPnvCazyBjNgZf+jpM U++D7xCoFkVq256e0w3iWSa8ezmxsWw+Ewtu3P6CpYElaZPSEVn5jdBQ0S9m33d2la TGxwZQ5YVZngbRPK+LqXqRtJIoaCh7FxR+nByLjQ= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729606AbfBDQyh (ORCPT ); Mon, 4 Feb 2019 11:54:37 -0500 Received: from mail.kernel.org ([198.145.29.99]:37896 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727308AbfBDQyg (ORCPT ); Mon, 4 Feb 2019 11:54:36 -0500 Received: from garbanzo.lan (c-73-71-40-85.hsd1.ca.comcast.net [73.71.40.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 818552186A; Mon, 4 Feb 2019 16:54:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1549299275; bh=7KNjaSuHH+NN+pp1Du29mzGZ1DulgXtmyY4eA6tMomo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=i7t7c+uc5keAznBKkHRoq/gKtmW6PP8zKO7om0t0SD4luJX3Gtf3YwzKLybQQ/8pk Zvpjto2aioJ7kBQJoaDyeWIYOPOfPaCeEPVH4pciRPYVj66mt9rhJficXUuWPa0Bel wzburfpD7nD+5iyL6bJcbKccMJ7dsP0jkQ2AqYmQ= From: Luis Chamberlain To: linux-xfs@vger.kernel.org, gregkh@linuxfoundation.org, Alexander.Levin@microsoft.com Cc: stable@vger.kernel.org, amir73il@gmail.com, hch@infradead.org, Brian Foster , "Darrick J . Wong" , Luis Chamberlain Subject: [PATCH v2 05/10] xfs: fix shared extent data corruption due to missing cow reservation Date: Mon, 4 Feb 2019 08:54:22 -0800 Message-Id: <20190204165427.23607-6-mcgrof@kernel.org> X-Mailer: git-send-email 2.18.0 In-Reply-To: <20190204165427.23607-1-mcgrof@kernel.org> References: <20190204165427.23607-1-mcgrof@kernel.org> Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Brian Foster commit 59e4293149106fb92530f8e56fa3992d8548c5e6 upstream. Page writeback indirectly handles shared extents via the existence of overlapping COW fork blocks. If COW fork blocks exist, writeback always performs the associated copy-on-write regardless if the underlying blocks are actually shared. If the blocks are shared, then overlapping COW fork blocks must always exist. fstests shared/010 reproduces a case where a buffered write occurs over a shared block without performing the requisite COW fork reservation. This ultimately causes writeback to the shared extent and data corruption that is detected across md5 checks of the filesystem across a mount cycle. The problem occurs when a buffered write lands over a shared extent that crosses an extent size hint boundary and that also happens to have a partial COW reservation that doesn't cover the start and end blocks of the data fork extent. For example, a buffered write occurs across the file offset (in FSB units) range of [29, 57]. A shared extent exists at blocks [29, 35] and COW reservation already exists at blocks [32, 34]. After accommodating a COW extent size hint of 32 blocks and the existing reservation at offset 32, xfs_reflink_reserve_cow() allocates 32 blocks of reservation at offset 0 and returns with COW reservation across the range of [0, 34]. The associated data fork extent is still [29, 35], however, which isn't fully covered by the COW reservation. This leads to a buffered write at file offset 35 over a shared extent without associated COW reservation. Writeback eventually kicks in, performs an overwrite of the underlying shared block and causes the associated data corruption. Update xfs_reflink_reserve_cow() to accommodate the fact that a delalloc allocation request may not fully cover the extent in the data fork. Trim the data fork extent appropriately, just as is done for shared extent boundaries and/or existing COW reservations that happen to overlap the start of the data fork extent. This prevents shared/010 failures due to data corruption on reflink enabled filesystems. Signed-off-by: Brian Foster Reviewed-by: Christoph Hellwig Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Luis Chamberlain --- fs/xfs/xfs_reflink.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/xfs/xfs_reflink.c b/fs/xfs/xfs_reflink.c index 42ea7bab9144..7088f44c0c59 100644 --- a/fs/xfs/xfs_reflink.c +++ b/fs/xfs/xfs_reflink.c @@ -302,6 +302,7 @@ xfs_reflink_reserve_cow( if (error) return error; + xfs_trim_extent(imap, got.br_startoff, got.br_blockcount); trace_xfs_reflink_cow_alloc(ip, &got); return 0; } -- 2.18.0