RE: FAILED: patch "[PATCH] ext4: fix data exposure after a crash" failed to apply to 3.14-stable tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Arend,

I am sorry for this misunderstanding.
Yes, I remember Jan Kara told me before.

Best regards

 Weller HUANG



> -----Original Message-----
> From: Arend van Spriel [mailto:arend.vanspriel@xxxxxxxxxxxx]
> Sent: Monday, June 06, 2016 1:17 PM
> To: HUANG Weller (CM/ESW12-CN) <Weller.Huang@xxxxxxxxxxxx>;
> gregkh@xxxxxxxxxxxxxxxxxxx; jack@xxxxxxx; tytso@xxxxxxx;
> backports@xxxxxxxxxxxxxxx
> Cc: stable@xxxxxxxxxxxxxxx; Behme Dirk (CM/ESO2)
> <Dirk.Behme@xxxxxxxxxxxx>; Juergens Dirk (CM/ESO2)
> <Dirk.Juergens@xxxxxxxxxxxx>
> Subject: Re: FAILED: patch "[PATCH] ext4: fix data exposure after a crash" failed
> to apply to 3.14-stable tree
> 
> On 06-06-16 02:02, HUANG Weller (CM/ESW12-CN) wrote:
> > Hi backports team,
> >
> > Could you please apply the below patch to the 3.14-stable tree ?
> 
> Hi Huang,
> 
> I suspect you are talking to the wrong crowd. Backports is a project to generate a
> source package of latest kernel code which can be compiled against older target
> kernels.
> 
> What is meant in Greg's (automated) response is that the patch should be
> backported manually so it applies to 3.14-stable tree. This is something Jan Kara
> should take care of if he cares about getting this patch in 3.14-stable.
> 
> Regards,
> Arend
> 
> > Thanks.
> > Best regards
> >
> >  Weller HUANG
> >
> >
> >
> >> -----Original Message-----
> >> From: gregkh@xxxxxxxxxxxxxxxxxxx [mailto:gregkh@xxxxxxxxxxxxxxxxxxx]
> >> Sent: Sunday, June 05, 2016 5:47 AM
> >> To: jack@xxxxxxx; HUANG Weller (CM/ESW12-CN)
> >> <Weller.Huang@xxxxxxxxxxxx>; tytso@xxxxxxx
> >> Cc: stable@xxxxxxxxxxxxxxx
> >> Subject: FAILED: patch "[PATCH] ext4: fix data exposure after a
> >> crash" failed to apply to 3.14-stable tree
> >>
> >>
> >> The patch below does not apply to the 3.14-stable tree.
> >> If someone wants it applied there, or to any other stable or longterm
> >> tree, then please email the backport, including the original git
> >> commit id to <stable@xxxxxxxxxxxxxxx>.
> >>
> >> thanks,
> >>
> >> greg k-h
> >>
> >> ------------------ original commit in Linus's tree ------------------
> >>
> >> From 06bd3c36a733ac27962fea7d6f47168841376824 Mon Sep 17 00:00:00
> >> 2001
> >> From: Jan Kara <jack@xxxxxxx>
> >> Date: Sun, 24 Apr 2016 00:56:03 -0400
> >> Subject: [PATCH] ext4: fix data exposure after a crash
> >>
> >> Huang has reported that in his powerfail testing he is seeing stale
> >> block contents in some of recently allocated blocks although he
> >> mounts
> >> ext4 in data=ordered mode. After some investigation I have found out
> >> that indeed when delayed allocation is used, we don't add inode to
> >> transaction's list of inodes needing flushing before commit.
> >> Originally we were doing that but commit f3b59291a69d removed the logic with
> a flawed argument that it is not needed.
> >>
> >> The problem is that although for delayed allocated blocks we write
> >> their contents immediately after allocating them, there is no
> >> guarantee that the IO scheduler or device doesn't reorder things and
> >> thus transaction allocating blocks and attaching them to inode can
> >> reach stable storage before actual block contents. Actually whenever
> >> we attach freshly allocated blocks to inode using a written extent,
> >> we should add inode to transaction's ordered inode list to make sure
> >> we properly wait for block contents to be written before committing
> >> the transaction. So that is what we do in this patch. This also handles other
> cases where stale data exposure was possible - like filling hole via mmap in
> data=ordered,nodelalloc mode.
> >>
> >> The only exception to the above rule are extending direct IO writes
> >> where
> >> blkdev_direct_IO() waits for IO to complete before increasing i_size
> >> and thus stale data exposure is not possible. For now we don't
> >> complicate the code with optimizing this special case since the
> >> overhead is pretty low. In case this is observed to be a performance
> >> problem we can always handle it using a special flag to ext4_map_blocks().
> >>
> >> CC: stable@xxxxxxxxxxxxxxx
> >> Fixes: f3b59291a69d0b734be1fc8be489fef2dd846d3d
> >> Reported-by: "HUANG Weller (CM/ESW12-CN)" <Weller.Huang@xxxxxxxxxxxx>
> >> Tested-by: "HUANG Weller (CM/ESW12-CN)" <Weller.Huang@xxxxxxxxxxxx>
> >> Signed-off-by: Jan Kara <jack@xxxxxxx>
> >> Signed-off-by: Theodore Ts'o <tytso@xxxxxxx>
> >>
> >> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index
> >> 981a1fc30eaa..250c2df04a92
> >> 100644
> >> --- a/fs/ext4/inode.c
> >> +++ b/fs/ext4/inode.c
> >> @@ -684,6 +684,21 @@ out_sem:
> >>  		ret = check_block_validity(inode, map);
> >>  		if (ret != 0)
> >>  			return ret;
> >> +
> >> +		/*
> >> +		 * Inodes with freshly allocated blocks where contents will be
> >> +		 * visible after transaction commit must be on transaction's
> >> +		 * ordered data list.
> >> +		 */
> >> +		if (map->m_flags & EXT4_MAP_NEW &&
> >> +		    !(map->m_flags & EXT4_MAP_UNWRITTEN) &&
> >> +		    !(flags & EXT4_GET_BLOCKS_ZERO) &&
> >> +		    !IS_NOQUOTA(inode) &&
> >> +		    ext4_should_order_data(inode)) {
> >> +			ret = ext4_jbd2_file_inode(handle, inode);
> >> +			if (ret)
> >> +				return ret;
> >> +		}
> >>  	}
> >>  	return retval;
> >>  }
> >> @@ -1289,15 +1304,6 @@ static int ext4_write_end(struct file *file,
> >>  	int i_size_changed = 0;
> >>
> >>  	trace_ext4_write_end(inode, pos, len, copied);
> >> -	if (ext4_test_inode_state(inode, EXT4_STATE_ORDERED_MODE)) {
> >> -		ret = ext4_jbd2_file_inode(handle, inode);
> >> -		if (ret) {
> >> -			unlock_page(page);
> >> -			put_page(page);
> >> -			goto errout;
> >> -		}
> >> -	}
> >> -
> >>  	if (ext4_has_inline_data(inode)) {
> >>  		ret = ext4_write_inline_data_end(inode, pos, len,
> >>  						 copied, page);
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe backports"
> > in
> >
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]