From: Steven Whitehouse <swhiteho@redhat.com>
To: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Dave Hansen <dave.hansen@linux.intel.com>,
Jan Kara <jack@suse.cz>, Al Viro <viro@zeniv.linux.org.uk>,
NeilBrown <neilb@suse.de>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] mm, fs: avoid page allocation beyond i_size on read
Date: Thu, 22 Aug 2013 16:34:55 +0100 [thread overview]
Message-ID: <1377185695.2720.79.camel@menhir> (raw)
In-Reply-To: <20130822151614.2F11DE0090@blue.fi.intel.com>
Hi,
On Thu, 2013-08-22 at 18:16 +0300, Kirill A. Shutemov wrote:
> Steven Whitehouse wrote:
> > Hi,
> >
> > On Thu, 2013-08-22 at 17:30 +0300, Kirill A. Shutemov wrote:
> > [snip]
> > > > Andrew's proposed solution makes sense to me, and is probably the
> > > > easiest way to solve this.
> > >
> > > Move check to no_cached_page?
> > Yes
> >
> > > I don't see how it makes any difference for
> > > page cache miss case: we anyway exclude ->readpage() if it's beyond local
> > > i_size.
> > > And for cache hit local i_size will be most likely cover locally cached
> > > pages.
> > The difference is that as the function is currently written, you cannot
> > get to no_cached_page without first calling page_cache_sync_readahead(),
> > i.e. ->readpages() so that i_size will have been updated, even if
> > ->readpages() doesn't return any read-ahead pages.
> >
> > I guess that it is not very obvious that a call to ->readpages is hidden
> > in page_cache_sync_readahead() but that is the path that should in the
> > common case provide the pages from the fs, rather than the ->readpage
> > call thats further down do_generic_file_read()
>
> I've checked the codepath before and to me it looks like ->readpages()
> will not be called beyond i_size. Codepath is:
>
> page_cache_sync_readahead()
> ondemand_readahead()
> __do_page_cache_readahead()
> read_pages()
> mapping->a_ops->readpages()
>
> But if you check __do_page_cache_readahead():
>
> 152 static int
> 153 __do_page_cache_readahead(struct address_space *mapping, struct file *filp,
> 154 pgoff_t offset, unsigned long nr_to_read,
> 155 unsigned long lookahead_size)
> 156 {
> ...
> 163 loff_t isize = i_size_read(inode);
> 164
> 165 if (isize == 0)
> 166 goto out;
> 167
> 168 end_index = ((isize - 1) >> PAGE_CACHE_SHIFT);
> ...
> 173 for (page_idx = 0; page_idx < nr_to_read; page_idx++) {
> 174 pgoff_t page_offset = offset + page_idx;
> 175
> 176 if (page_offset > end_index)
> 177 break;
> ...
> 193 }
> ...
> 200 if (ret)
> 201 read_pages(mapping, filp, &page_pool, ret);
> 202 BUG_ON(!list_empty(&page_pool));
> 203 out:
> 204 return ret;
> 205 }
>
> Do I miss something?
>
Hrm. It looks like that Andrew's proposal is not going to work then :(
The trouble is that readahead has broken silently in this one case,
since the net result of the readahead not going ahead at this point, is
that ->readpage will be called later on. So in the cases where it
matters (i.e. i_size updated remotely), we'd probably not have noticed
it before as the read will still return successfully.
That is real problem though... so maybe this isn't as easy as I'd first
thought,
Steve.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
prev parent reply other threads:[~2013-08-22 15:34 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1377099441-2224-1-git-send-email-kirill.shutemov@linux.intel.com>
[not found] ` <1377100012.2738.28.camel@menhir>
[not found] ` <20130821160817.940D3E0090@blue.fi.intel.com>
[not found] ` <1377103332.2738.37.camel@menhir>
[not found] ` <20130821135821.fc8f5a2551a28c9ce9c4b049@linux-foundation.org>
[not found] ` <1377163725.2720.18.camel@menhir>
2013-08-22 13:05 ` [PATCH] mm, fs: avoid page allocation beyond i_size on read Kirill A. Shutemov
2013-08-22 13:33 ` Steven Whitehouse
2013-08-22 14:30 ` Kirill A. Shutemov
2013-08-22 14:59 ` Steven Whitehouse
2013-08-22 15:16 ` Kirill A. Shutemov
2013-08-22 15:34 ` Steven Whitehouse [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1377185695.2720.79.camel@menhir \
--to=swhiteho@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=dave.hansen@linux.intel.com \
--cc=jack@suse.cz \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=neilb@suse.de \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).