linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
To: Steven Whitehouse <swhiteho@redhat.com>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	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
Subject: Re: [PATCH] mm, fs: avoid page allocation beyond i_size on read
Date: Wed, 21 Aug 2013 19:08:17 +0300 (EEST)	[thread overview]
Message-ID: <20130821160817.940D3E0090@blue.fi.intel.com> (raw)
In-Reply-To: <1377100012.2738.28.camel@menhir>

Steven Whitehouse wrote:
> Hi,
> 
> On Wed, 2013-08-21 at 18:37 +0300, Kirill A. Shutemov wrote:
> > I've noticed that we allocated unneeded page for cache on read beyond
> > i_size. Simple test case (I checked it on ramfs):
> > 
> > $ touch testfile
> > $ cat testfile
> > 
> > It triggers 'no_cached_page' code path in do_generic_file_read().
> > 
> > Looks like it's regression since commit a32ea1e. Let's fix it.
> > 
> > Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
> > Acked-by: NeilBrown <neilb@suse.de>
> > ---
> >  mm/filemap.c | 4 ++++
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/mm/filemap.c b/mm/filemap.c
> > index 1905f0e..b1a4d35 100644
> > --- a/mm/filemap.c
> > +++ b/mm/filemap.c
> > @@ -1163,6 +1163,10 @@ static void do_generic_file_read(struct file *filp, loff_t *ppos,
> >  		loff_t isize;
> >  		unsigned long nr, ret;
> >  
> > +		isize = i_size_read(inode);
> > +		if (!isize || index > (isize - 1) >> PAGE_CACHE_SHIFT)
> > +			goto out;
> > +
> >  		cond_resched();
> >  find_page:
> >  		page = find_get_page(mapping, index);
> 
> Please don't do that... there is no reason to think that i_size will be
> correct at that moment. Why not just get readpage(s) to return the
> correct return code in that case?

I work on THP for page cache. Allocation and clearing a huge page for
nothing is pretty expensive.

I don't think the change is harmful. The worst case scenario is race with
write or truncate, but it's valid to return EOF in this case.

What scenario do you have in mind?

-- 
 Kirill A. Shutemov

--
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-21 16:08 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-21 15:37 [PATCH] mm, fs: avoid page allocation beyond i_size on read Kirill A. Shutemov
2013-08-21 15:46 ` Steven Whitehouse
2013-08-21 16:08   ` Kirill A. Shutemov [this message]
2013-08-21 16:42     ` Steven Whitehouse
2013-08-21 20:58       ` Andrew Morton
2013-08-22  9:28         ` Steven Whitehouse
2013-08-22 13:05           ` 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

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=20130821160817.940D3E0090@blue.fi.intel.com \
    --to=kirill.shutemov@linux.intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=dave.hansen@linux.intel.com \
    --cc=jack@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=neilb@suse.de \
    --cc=swhiteho@redhat.com \
    --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).