Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp2079990imu; Wed, 28 Nov 2018 22:01:31 -0800 (PST) X-Google-Smtp-Source: AFSGD/W4VGobsS6w7HMSu3z7Sj0VufyeEuU5w2VyP2C4JEPybQOORTPGKKBrAD6di8Sb8ixTJKWT X-Received: by 2002:a62:2cf:: with SMTP id 198mr180148pfc.67.1543471291735; Wed, 28 Nov 2018 22:01:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543471291; cv=none; d=google.com; s=arc-20160816; b=rn5ygSDTNN8KtdE8wNT74e80iX08TvuE6g4KYgSCXvH6wCzKY1nTe3yd2i/ox5vv8Y YAZ+EjYG7IgxOxRkiEtEg29+YSSNIXETNx/De+BMZAj9ah5Jfcn7d9irArnIXVxdOSgg qSBIhkPvWWg6vrsWGfeTdqlnORwlzl3dxoQoAkqGxuSdmXR/8MptF2msPoRp3JUh+FCN il/vXpqpxhr+sKHdfw+O4elFqdZ4NsOPyL8BXZ5BUDXvkKbmz8xs7DI95J2G4r8EwP24 9MOJNTLFJTiSd8MbANCgKw4wbV5udee0ZpIjRNbTBBVL4qdavZ68mhCKwhrJ4OBnjH/6 rH7g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:dkim-signature; bh=WwgcSB+rwd09aOwYPeqAzHdKzk5OrEUpWgRPljapDIo=; b=pXDteJBCCcyD1Fks5Mq1nzwpW+iX96f/XUeKQ1T0E1RP3i1dSELO+JMe4mP2Lk2aHh 3dKyfjy3kNUOeN2jcMLKW7584oHyb6XnR+dKKDnUXJ0y4PuS7vzjE169fLEsR02ZM6rX IdgUoplSafjaMsov8/5DXPN51jrOoZ/ruuIuuiciLlkbu/8OyYnDoSr4mHwyD5TEcP2n jkcqZiMBj9vYaLpk5NYov72plOYAUWQJJ2KqSCL4yu0fYQs+e81D0SZiSYFd0TmLOwag qKf66qaWqjJ8Oqf3m81ELGsuxWcnmCzAuMvz8o0cvpWEfQTTacLhgRULWq0b4axLf766 zDwA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=J3z6TBUr; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k11si1010618pgg.430.2018.11.28.22.01.17; Wed, 28 Nov 2018 22:01:31 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=J3z6TBUr; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729048AbeK2REO (ORCPT + 99 others); Thu, 29 Nov 2018 12:04:14 -0500 Received: from mail.kernel.org ([198.145.29.99]:38816 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727570AbeK2REN (ORCPT ); Thu, 29 Nov 2018 12:04:13 -0500 Received: from sasha-vm.mshome.net (unknown [37.142.5.207]) (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 6836921019; Thu, 29 Nov 2018 06:00:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1543471202; bh=DQ3ixg0MFFH2XgMjali88FIJqJohl84f9waLu0eLn4Y=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=J3z6TBUr775tXtpzErfXjUgsiuaWvReLin6UXDjgGTRVLv2yCdFRiDwUS9TtifuJX wklYnXexwlErQaSHP6eIUVbhVSaCFAm7o6upK/TeoGaa35blci6rbR2abGrcEFiCVr TMUfbEYUsWICkmH2t2HcNDjfkMrcjZr/JZxifkQA= From: Sasha Levin To: stable@vger.kernel.org, linux-kernel@vger.kernel.org Cc: Dave Chinner , "Darrick J . Wong" , Sasha Levin , linux-fsdevel@vger.kernel.org Subject: [PATCH AUTOSEL 4.19 51/68] iomap: FUA is wrong for DIO O_DSYNC writes into unwritten extents Date: Thu, 29 Nov 2018 00:55:42 -0500 Message-Id: <20181129055559.159228-51-sashal@kernel.org> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20181129055559.159228-1-sashal@kernel.org> References: <20181129055559.159228-1-sashal@kernel.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Dave Chinner [ Upstream commit 0929d8580071c6a1cec1a7916a8f674c243ceee1 ] When we write into an unwritten extent via direct IO, we dirty metadata on IO completion to convert the unwritten extent to written. However, when we do the FUA optimisation checks, the inode may be clean and so we issue a FUA write into the unwritten extent. This means we then bypass the generic_write_sync() call after unwritten extent conversion has ben done and we don't force the modified metadata to stable storage. This violates O_DSYNC semantics. The window of exposure is a single IO, as the next DIO write will see the inode has dirty metadata and hence will not use the FUA optimisation. Calling generic_write_sync() after completion of the second IO will also sync the first write and it's metadata. Fix this by avoiding the FUA optimisation when writing to unwritten extents. Signed-off-by: Dave Chinner Reviewed-by: Christoph Hellwig Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Sasha Levin --- fs/iomap.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/fs/iomap.c b/fs/iomap.c index ec15cf2ec696..fa46e3ed8f53 100644 --- a/fs/iomap.c +++ b/fs/iomap.c @@ -1597,12 +1597,13 @@ iomap_dio_bio_actor(struct inode *inode, loff_t pos, loff_t length, if (iomap->flags & IOMAP_F_NEW) { need_zeroout = true; - } else { + } else if (iomap->type == IOMAP_MAPPED) { /* - * Use a FUA write if we need datasync semantics, this - * is a pure data IO that doesn't require any metadata - * updates and the underlying device supports FUA. This - * allows us to avoid cache flushes on IO completion. + * Use a FUA write if we need datasync semantics, this is a pure + * data IO that doesn't require any metadata updates (including + * after IO completion such as unwritten extent conversion) and + * the underlying device supports FUA. This allows us to avoid + * cache flushes on IO completion. */ if (!(iomap->flags & (IOMAP_F_SHARED|IOMAP_F_DIRTY)) && (dio->flags & IOMAP_DIO_WRITE_FUA) && -- 2.17.1