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 linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
