On Wed, Jan 25, 2017 at 01:49:09PM +0530, Chandan Rajendra wrote:
> On Tuesday, January 24, 2017 03:58:51 PM Liu Bo wrote:
> > Commit "d0b7da88 Btrfs: btrfs_page_mkwrite: Reserve space in sectorsized units"
> > did this, but btrfs_lookup_ordered_range expects a 'length' rather than a
> > 'page_end'.
> >
> > Signed-off-by: Liu Bo <bo.li.liu@xxxxxxxxxx>
> > ---
> > Is this a candidate for stable?
> >
> > fs/btrfs/inode.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
> > index 4e02426..366cf0b 100644
> > --- a/fs/btrfs/inode.c
> > +++ b/fs/btrfs/inode.c
> > @@ -9023,7 +9023,7 @@ int btrfs_page_mkwrite(struct vm_area_struct *vma, struct vm_fault *vmf)
> > * we can't set the delalloc bits if there are pending ordered
> > * extents. Drop our locks and wait for them to finish
> > */
> > - ordered = btrfs_lookup_ordered_range(inode, page_start, page_end);
> > + ordered = btrfs_lookup_ordered_range(inode, page_start, PAGE_SIZE);
> > if (ordered) {
> > unlock_extent_cached(io_tree, page_start, page_end,
> > &cached_state, GFP_NOFS);
> >
>
> Thanks for fixing this,
> Reviewed-by: Chandan Rajendra <chandan@xxxxxxxxxxxxxxxxxx>
>
> As for the question about whether this commit should be merged into the stable
> trees ... I am not sure about that since I don't notice any sort of filesystem
> corruption that can be caused by the current code i.e. With the existing code,
> apart from any ordered extents that map the page in question, we are most
> likely to be *unnecessarily* starting i/o on ordered extents that don't map
> the file offset range covered by the page. Chris, Josef or David, Please let
> us know your thoughts on this.
It could be a performance regression which causes fault writes have
unnecessary waits instead of a real corruption.
Thanks,
-liubo
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
