linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Steven Whitehouse <swhiteho@redhat.com>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	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 13:58:21 -0700	[thread overview]
Message-ID: <20130821135821.fc8f5a2551a28c9ce9c4b049@linux-foundation.org> (raw)
In-Reply-To: <1377103332.2738.37.camel@menhir>

On Wed, 21 Aug 2013 17:42:12 +0100 Steven Whitehouse <swhiteho@redhat.com> wrote:

> > 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?
> > 
> 
> 1. File open on node A
> 2. Someone updates it on node B by extending the file
> 3. Someone reads the file on node A beyond end of original file size,
> but within end of new file size as updated by node B. Without the patch
> this works, with it, it will fail. The reason being the i_size would not
> be up to date until after readpage(s) has been called.
> 
> I think this is likely to be an issue for any distributed fs using
> do_generic_file_read(), although it would certainly affect GFS2, since
> the locking is done at page cache level,

Boy, that's rather subtle.  I'm surprised that the generic filemap.c
stuff works at all in that sort of scenario.

Can we put the i_size check down in the no_cached_page block?  afaict
that will solve the problem without breaking GFS2 and is more
efficient?

--
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 20:58 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
2013-08-21 16:42     ` Steven Whitehouse
2013-08-21 20:58       ` Andrew Morton [this message]
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=20130821135821.fc8f5a2551a28c9ce9c4b049@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=dave.hansen@linux.intel.com \
    --cc=jack@suse.cz \
    --cc=kirill.shutemov@linux.intel.com \
    --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).