]> git.proxmox.com Git - mirror_ubuntu-hirsute-kernel.git/commit - mm/filemap.c
mm: remove optimizations based on i_size in mapping writeback waits
authorJeff Layton <jlayton@redhat.com>
Mon, 31 Jul 2017 14:29:38 +0000 (10:29 -0400)
committerJeff Layton <jlayton@redhat.com>
Tue, 1 Aug 2017 12:39:29 +0000 (08:39 -0400)
commitffb959bbdf923b4f89a08a04aba2501b1b16d164
treefa248b66c3b36982ee41ca1c51807b453b4d9e22
parent3b49c9a1e984b524142afc7536041d8c66877113
mm: remove optimizations based on i_size in mapping writeback waits

Marcelo added this i_size based optimization with a patch in 2004
(commitid is from the linux-history tree):

    commit 765dad09b4ac101a32d87af2bb793c3060497d3c
    Author: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
    Date:   Tue Sep 7 17:51:17 2004 -0700

small wait_on_page_writeback_range() optimization

filemap_fdatawait() calls wait_on_page_writeback_range() with -1
as "end" parameter.  This is not needed since we know the EOF
from the inode.  Use that instead.

There may be races here, particularly with clustered or network
filesystems. It also seems like a bit of a layering violation since
we're operating on an address_space here, not an inode.

Finally, it's also questionable whether this optimization really helps
on workloads that we care about. Should we be optimizing for writeback
vs. truncate races in a codepath where we expect to wait anyway? It
doesn't seem worth the risk.

Remove this optimization from the filemap_fdatawait codepaths. This
means that filemap_fdatawait becomes a trivial wrapper around
filemap_fdatawait_range.

Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
include/linux/fs.h
mm/filemap.c