On Fri 17-11-17 13:30:16, Ben Hutchings wrote: > On Thu, 2017-11-16 at 17:07 -0500, Theodore Ts'o wrote: > > On Thu, Nov 16, 2017 at 12:29:56PM +0100, Greg Kroah-Hartman wrote: > > > On Wed, Nov 15, 2017 at 09:10:46PM +0000, Ben Hutchings wrote: > > > > Please apply the attached backported patches to 4.4-stable. The > > > > upstream commits are: > > > > > > > > 06bd3c36a733 ext4: fix data exposure after a crash > > > > > > This patch did not apply, and when I worked at it by hand to apply, it > > > then broke the build with: > > > fs/ext4/inode.c: In function ‘ext4_map_blocks’: > > > fs/ext4/inode.c:669:17: error: ‘EXT4_GET_BLOCKS_ZERO’ undeclared (first use in this function); did you mean ‘EXT4_GET_BLOCKS_PRE_IO’? > > > !(flags & EXT4_GET_BLOCKS_ZERO) && > > > ^~~~~~~~~~~~~~~~~~~~ > > > > > > As Ted didn't provide this on the list of ext4 patches to backport to > > > 4.4 in the past, I'm a bit hesitant to take this now. Are you sure it > > > is needed? > > > > As Greg noted, EXT4_GET_BLOCKS_ZERO is not in the Linux 4.4 kernel. > > To make this works requires at least three pre-requisite commits: > > > > 2dcba4781fa3: ext4: get rid of EXT4_GET_BLOCKS_NO_LOCK flag > > 53085fac02d1: ext4: provide ext4_issue_zeroout() > > c86d8db33a92: ext4: implement allocation of pre-zeroed blocks > [...] > > I previously backported this to 3.16 and simply removed that flag > check, on the basis that the feature it represents is not supported at > all. The backports to 3.10 and 3.12, and the backport I sent to Greg > for 4.4 (as an attachment), also made that change. Are you saying that > a backport of the fix actually needs to check for a similar condition, > even in branches where the flag doesn't exist? No, you did the right thing. Just removing the !(flags & EXT4_GET_BLOCKS_ZERO) check is the right thing to do for the kernels not supporting EXT4_GET_BLOCKS_ZERO. The rationale is: The condition just avoids adding inode to transaction's list when we know blocks were zeroed-out by the allocator. For kernels not supporting zeroing in the allocator we can just remove this optimization. Thanks for sending the backports! Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR