On Wed 21-09-16 09:22:44, Ross Zwisler wrote: > On Tue, Aug 23, 2016 at 04:04:11PM -0600, Ross Zwisler wrote: > > Currently when doing a DAX hole punch with ext4 we fail to do a writeback. > > This is because the logic around filemap_write_and_wait_range() in > > ext4_punch_hole() only looks for dirty page cache pages in the radix tree, > > not for dirty DAX exceptional entries. > > > > Signed-off-by: Ross Zwisler <ross.zwisler@xxxxxxxxxxxxxxx> > > Reviewed-by: Jan Kara <jack@xxxxxxx> > > Cc: <stable@xxxxxxxxxxxxxxx> > > Ted & Jan, > > I'm still working on the latest version of the PMD work which integrates with > the new struct iomap faults. At this point it doesn't look like I'm going to > make v4.9, but I think that this bug fix at least should probably go in alone? Yeah. Ted, feel free to add: Reviewed-by: Jan Kara <jack@xxxxxxx> and merge this change. Thanks! Honza > > fs/ext4/inode.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c > > index 3131747..0900cb4 100644 > > --- a/fs/ext4/inode.c > > +++ b/fs/ext4/inode.c > > @@ -3890,7 +3890,7 @@ int ext4_update_disksize_before_punch(struct inode *inode, loff_t offset, > > } > > > > /* > > - * ext4_punch_hole: punches a hole in a file by releaseing the blocks > > + * ext4_punch_hole: punches a hole in a file by releasing the blocks > > * associated with the given offset and length > > * > > * @inode: File inode > > @@ -3919,7 +3919,7 @@ int ext4_punch_hole(struct inode *inode, loff_t offset, loff_t length) > > * Write out all dirty pages to avoid race conditions > > * Then release them. > > */ > > - if (mapping->nrpages && mapping_tagged(mapping, PAGECACHE_TAG_DIRTY)) { > > + if (mapping_tagged(mapping, PAGECACHE_TAG_DIRTY)) { > > ret = filemap_write_and_wait_range(mapping, offset, > > offset + length - 1); > > if (ret) > > -- > > 2.9.0 > > -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR -- 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