From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linuxfoundation.org ([140.211.169.12]:34044 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752358AbdFLIzP (ORCPT ); Mon, 12 Jun 2017 04:55:15 -0400 Subject: Patch "ext4: fix fdatasync(2) after extent manipulation operations" has been added to the 4.11-stable tree To: jack@suse.cz, gregkh@linuxfoundation.org, tytso@mit.edu Cc: , From: Date: Mon, 12 Jun 2017 10:54:58 +0200 Message-ID: <149725769810371@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ANSI_X3.4-1968 Content-Transfer-Encoding: 8bit Sender: stable-owner@vger.kernel.org List-ID: This is a note to let you know that I've just added the patch titled ext4: fix fdatasync(2) after extent manipulation operations to the 4.11-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: ext4-fix-fdatasync-2-after-extent-manipulation-operations.patch and it can be found in the queue-4.11 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let know about it. >>From 67a7d5f561f469ad2fa5154d2888258ab8e6df7c Mon Sep 17 00:00:00 2001 From: Jan Kara Date: Mon, 29 May 2017 13:24:55 -0400 Subject: ext4: fix fdatasync(2) after extent manipulation operations From: Jan Kara commit 67a7d5f561f469ad2fa5154d2888258ab8e6df7c upstream. Currently, extent manipulation operations such as hole punch, range zeroing, or extent shifting do not record the fact that file data has changed and thus fdatasync(2) has a work to do. As a result if we crash e.g. after a punch hole and fdatasync, user can still possibly see the punched out data after journal replay. Test generic/392 fails due to these problems. Fix the problem by properly marking that file data has changed in these operations. Fixes: a4bb6b64e39abc0e41ca077725f2a72c868e7622 Signed-off-by: Jan Kara Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman --- fs/ext4/extents.c | 5 +++++ fs/ext4/inode.c | 2 ++ 2 files changed, 7 insertions(+) --- a/fs/ext4/extents.c +++ b/fs/ext4/extents.c @@ -4877,6 +4877,8 @@ static long ext4_zero_range(struct file /* Zero out partial block at the edges of the range */ ret = ext4_zero_partial_blocks(handle, inode, offset, len); + if (ret >= 0) + ext4_update_inode_fsync_trans(handle, inode, 1); if (file->f_flags & O_SYNC) ext4_handle_sync(handle); @@ -5563,6 +5565,7 @@ int ext4_collapse_range(struct inode *in ext4_handle_sync(handle); inode->i_mtime = inode->i_ctime = current_time(inode); ext4_mark_inode_dirty(handle, inode); + ext4_update_inode_fsync_trans(handle, inode, 1); out_stop: ext4_journal_stop(handle); @@ -5736,6 +5739,8 @@ int ext4_insert_range(struct inode *inod up_write(&EXT4_I(inode)->i_data_sem); if (IS_SYNC(inode)) ext4_handle_sync(handle); + if (ret >= 0) + ext4_update_inode_fsync_trans(handle, inode, 1); out_stop: ext4_journal_stop(handle); --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -4165,6 +4165,8 @@ int ext4_punch_hole(struct inode *inode, inode->i_mtime = inode->i_ctime = current_time(inode); ext4_mark_inode_dirty(handle, inode); + if (ret >= 0) + ext4_update_inode_fsync_trans(handle, inode, 1); out_stop: ext4_journal_stop(handle); out_dio: Patches currently in stable-queue which might be from jack@suse.cz are queue-4.11/reiserfs-make-flush-bios-explicitely-sync.patch queue-4.11/ext4-fix-data-corruption-with-ext4_get_blocks_zero.patch queue-4.11/cfq-iosched-fix-the-delay-of-cfq_group-s-vdisktime-under-iops-mode.patch queue-4.11/ext4-fix-fdatasync-2-after-extent-manipulation-operations.patch queue-4.11/gfs2-make-flush-bios-explicitely-sync.patch queue-4.11/block-avoid-that-blk_exit_rl-triggers-a-use-after-free.patch queue-4.11/ext4-fix-seek_hole.patch