linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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>

      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).