Received: by 10.223.185.116 with SMTP id b49csp6348318wrg; Wed, 28 Feb 2018 08:00:09 -0800 (PST) X-Google-Smtp-Source: AG47ELujSt3azidgfynsOxBXb0/7XUpZNvAoeJdF5R9lYdOVhuzm9NFHmNQm61PSYe2zaqYP9kvo X-Received: by 10.98.185.11 with SMTP id z11mr7600474pfe.153.1519833609357; Wed, 28 Feb 2018 08:00:09 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519833609; cv=none; d=google.com; s=arc-20160816; b=ESZDermEXm+CsONc2VzRc5zCXgmBtd0GV3uvYNrd1llJCd2+IAbd6EgCtfCfcKu3i3 aolRPAwfB+wB/HHTBmg/N73NplmVLQ9IgTyPkcWGvEWPn+mO2SGqIrSoesN5C1Ro/3un LM0QZl+GIZDQpxvViqybl/Xv0pXjKg94cf94jGCIMibvK7OSfpxg1IWRKDQDm4bJfdaL pvXcveo0SynY9yw2wm1KjwuE5AVby/kJOj7Moixifu9ePWGwJAWGcgntLBbC+OS/eosX mOslp+fnjnizSHmMkMZMhQul3eLpq5ccQ+IiWQchcRa/S5NI8jcK9lubDBsnZlypbZON HYpg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:subject:message-id:date:cc:to :from:mime-version:content-transfer-encoding:content-disposition :arc-authentication-results; bh=Wgp2u5iB38VSyyZz7FlMuInq6aTvQva/5qzJGbJbQKc=; b=pASGrE/4EmQp4kXQw31tcVQpILNbUyhzXeH8R3yeuWasDQqgot1nXo6OxhsrorpX3S Cf8jT2YUHM/o7c5rRcwi7prM0Xye8hcvmUIzFnUzud3yfmaWlea2Ixx2o1zh2zf1H2La YAn/vQr0E06tcCLMfyNnsnweqoCph+PmYp2oM6ldYlD1fv2CJb+D3NG2KEdJx2g3Ie2X 1BW/xzP2KprJ71vnVnsipZuwg8fBmNGMTk/WurAkYkJmo8D8gqb5Z2xbvPESKApOlTy1 IVesqm1tp9dMndI+1Rn7PTd+SFurtHKZSeRWVBlSnL/cyyWdnYYhfsjzHO/gtkCbcJGb TZVQ== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j73si1130636pgc.566.2018.02.28.07.59.54; Wed, 28 Feb 2018 08:00:09 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934246AbeB1P61 (ORCPT + 99 others); Wed, 28 Feb 2018 10:58:27 -0500 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:34559 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934242AbeB1P6Y (ORCPT ); Wed, 28 Feb 2018 10:58:24 -0500 Received: from [2a02:8011:400e:2:6f00:88c8:c921:d332] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1er3Yu-0006XT-Bt; Wed, 28 Feb 2018 15:22:32 +0000 Received: from ben by deadeye with local (Exim 4.90_1) (envelope-from ) id 1er3Ye-0008QY-BJ; Wed, 28 Feb 2018 15:22:16 +0000 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org CC: akpm@linux-foundation.org, "Theodore Ts'o" , "Eryu Guan" Date: Wed, 28 Feb 2018 15:20:18 +0000 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) Subject: [PATCH 3.16 048/254] ext4: fix fdatasync(2) after fallocate(2) operation In-Reply-To: X-SA-Exim-Connect-IP: 2a02:8011:400e:2:6f00:88c8:c921:d332 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.16.55-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Eryu Guan commit c894aa97577e47d3066b27b32499ecf899bfa8b0 upstream. Currently, fallocate(2) with KEEP_SIZE followed by a fdatasync(2) then crash, we'll see wrong allocated block number (stat -c %b), the blocks allocated beyond EOF are all lost. fstests generic/468 exposes this bug. Commit 67a7d5f561f4 ("ext4: fix fdatasync(2) after extent manipulation operations") fixed all the other extent manipulation operation paths such as hole punch, zero range, collapse range etc., but forgot the fallocate case. So similarly, fix it by recording the correct journal tid in ext4 inode in fallocate(2) path, so that ext4_sync_file() will wait for the right tid to be committed on fdatasync(2). This addresses the test failure in xfstests test generic/468. Signed-off-by: Eryu Guan Signed-off-by: Theodore Ts'o Signed-off-by: Ben Hutchings --- fs/ext4/extents.c | 1 + 1 file changed, 1 insertion(+) --- a/fs/ext4/extents.c +++ b/fs/ext4/extents.c @@ -4726,6 +4726,7 @@ retry: EXT4_INODE_EOFBLOCKS); } ext4_mark_inode_dirty(handle, inode); + ext4_update_inode_fsync_trans(handle, inode, 1); ret2 = ext4_journal_stop(handle); if (ret2) break;