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=-10.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=unavailable 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 48BAFC43603 for ; Wed, 11 Dec 2019 15:45:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 1EBD22173E for ; Wed, 11 Dec 2019 15:45:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1576079125; bh=9MJpB7t1Y1QQG2Yy3v7yUvWRZdfdBtNnwQoHMf2LRAA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=YbJ+/hCBTS6+xnkPL/T9A9NYUsPP8D+OGSzoay9TpTuaYt3oOpAItLg0Sr6/SXFYh QRltrSr0IUf9RvyxzQlMVq/nuaNZznpSsZ6TmuS6IGxvl3oMnEmjy5R4atXmtJAoOm VDMAJwKf0UvVcQd9oNGO+SxBkxuaYmhOoVxMVpuc= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388606AbfLKPpY (ORCPT ); Wed, 11 Dec 2019 10:45:24 -0500 Received: from mail.kernel.org ([198.145.29.99]:60898 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1733211AbfLKP1K (ORCPT ); Wed, 11 Dec 2019 10:27:10 -0500 Received: from sasha-vm.mshome.net (c-73-47-72-35.hsd1.nh.comcast.net [73.47.72.35]) (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 12D6F208C3; Wed, 11 Dec 2019 15:27:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1576078029; bh=9MJpB7t1Y1QQG2Yy3v7yUvWRZdfdBtNnwQoHMf2LRAA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=V/VbddDjMx25+v/KCcJU6Us1Ifb4+/bkR7AT/bxIhYVuvkx1RDIqvD8oyuM1jgiBj dssWKaQjcw3RZkswzRWEI7Ot5x9oqvwGLnPhc5qaR2MpgoNBtt7Eai417r/VebDw0N hjHzyY2nNmtFst7j5U7R59Nfuhelv93ZJ0a1v8wY= From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Matthew Bobrowski , Jan Kara , Ritesh Harjani , Theodore Ts'o , Sasha Levin , linux-ext4@vger.kernel.org Subject: [PATCH AUTOSEL 4.19 24/79] ext4: iomap that extends beyond EOF should be marked dirty Date: Wed, 11 Dec 2019 10:25:48 -0500 Message-Id: <20191211152643.23056-24-sashal@kernel.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20191211152643.23056-1-sashal@kernel.org> References: <20191211152643.23056-1-sashal@kernel.org> MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Matthew Bobrowski [ Upstream commit 2e9b51d78229d5145725a481bb5464ebc0a3f9b2 ] This patch addresses what Dave Chinner had discovered and fixed within commit: 7684e2c4384d. This changes does not have any user visible impact for ext4 as none of the current users of ext4_iomap_begin() that extend files depend on IOMAP_F_DIRTY. When doing a direct IO that spans the current EOF, and there are written blocks beyond EOF that extend beyond the current write, the only metadata update that needs to be done is a file size extension. However, we don't mark such iomaps as IOMAP_F_DIRTY to indicate that there is IO completion metadata updates required, and hence we may fail to correctly sync file size extensions made in IO completion when O_DSYNC writes are being used and the hardware supports FUA. Hence when setting IOMAP_F_DIRTY, we need to also take into account whether the iomap spans the current EOF. If it does, then we need to mark it dirty so that IO completion will call generic_write_sync() to flush the inode size update to stable storage correctly. Signed-off-by: Matthew Bobrowski Reviewed-by: Jan Kara Reviewed-by: Ritesh Harjani Link: https://lore.kernel.org/r/8b43ee9ee94bee5328da56ba0909b7d2229ef150.1572949325.git.mbobrowski@mbobrowski.org Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin --- fs/ext4/inode.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index 00d25a0643913..8eaf7a581be65 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -3535,8 +3535,14 @@ retry: return ret; } + /* + * Writes that span EOF might trigger an I/O size update on completion, + * so consider them to be dirty for the purposes of O_DSYNC, even if + * there is no other metadata changes being made or are pending here. + */ iomap->flags = 0; - if (ext4_inode_datasync_dirty(inode)) + if (ext4_inode_datasync_dirty(inode) || + offset + length > i_size_read(inode)) iomap->flags |= IOMAP_F_DIRTY; iomap->bdev = inode->i_sb->s_bdev; iomap->dax_dev = sbi->s_daxdev; -- 2.20.1