Re: [PATCH] mm, fs: avoid page allocation beyond i_size on read

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

Re: [PATCH] mm, fs: avoid page allocation beyond i_size on read

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

Re: [PATCH] mm, fs: avoid page allocation beyond i_size on read

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

Re: [PATCH] mm, fs: avoid page allocation beyond i_size on read

Steven Whitehouse wrote: > Hi, > > On Thu, 2013-08-22 at 16:05 +0300, Kirill A. Shutemov wrote: > > Steven Whitehouse wrote: > > > Hi, > > > > > > On Wed, 2013-08-21 at 13:58 -0700, Andrew Morton wrote: > > > > On Wed, 21 Aug 2013 17:42:12 +0100 Steven Whitehouse > > > > wrote: > > > > > > >

Re: [PATCH] mm, fs: avoid page allocation beyond i_size on read

Hi, On Thu, 2013-08-22 at 16:05 +0300, Kirill A. Shutemov wrote: > Steven Whitehouse wrote: > > Hi, > > > > On Wed, 2013-08-21 at 13:58 -0700, Andrew Morton wrote: > > > On Wed, 21 Aug 2013 17:42:12 +0100 Steven Whitehouse > > > wrote: > > > > > > > > I don't think the change is harmful. The

Re: [PATCH] mm, fs: avoid page allocation beyond i_size on read

Steven Whitehouse wrote: > Hi, > > On Wed, 2013-08-21 at 13:58 -0700, Andrew Morton wrote: > > On Wed, 21 Aug 2013 17:42:12 +0100 Steven Whitehouse > > wrote: > > > > > > I don't think the change is harmful. The worst case scenario is race > > > > with > > > > write or truncate, but it's

Re: [PATCH] mm, fs: avoid page allocation beyond i_size on read

Hi, On Wed, 2013-08-21 at 13:58 -0700, Andrew Morton wrote: > On Wed, 21 Aug 2013 17:42:12 +0100 Steven Whitehouse > 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

Re: [PATCH] mm, fs: avoid page allocation beyond i_size on read

Hi, On Wed, 2013-08-21 at 13:58 -0700, Andrew Morton wrote: On Wed, 21 Aug 2013 17:42:12 +0100 Steven Whitehouse swhit...@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.

Re: [PATCH] mm, fs: avoid page allocation beyond i_size on read

Steven Whitehouse wrote: Hi, On Wed, 2013-08-21 at 13:58 -0700, Andrew Morton wrote: On Wed, 21 Aug 2013 17:42:12 +0100 Steven Whitehouse swhit...@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

Re: [PATCH] mm, fs: avoid page allocation beyond i_size on read

Hi, On Thu, 2013-08-22 at 16:05 +0300, Kirill A. Shutemov wrote: Steven Whitehouse wrote: Hi, On Wed, 2013-08-21 at 13:58 -0700, Andrew Morton wrote: On Wed, 21 Aug 2013 17:42:12 +0100 Steven Whitehouse swhit...@redhat.com wrote: I don't think the change is harmful. The

Re: [PATCH] mm, fs: avoid page allocation beyond i_size on read

Steven Whitehouse wrote: Hi, On Thu, 2013-08-22 at 16:05 +0300, Kirill A. Shutemov wrote: Steven Whitehouse wrote: Hi, On Wed, 2013-08-21 at 13:58 -0700, Andrew Morton wrote: On Wed, 21 Aug 2013 17:42:12 +0100 Steven Whitehouse swhit...@redhat.com wrote: I don't

Re: [PATCH] mm, fs: avoid page allocation beyond i_size on read

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

Re: [PATCH] mm, fs: avoid page allocation beyond i_size on read

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

Re: [PATCH] mm, fs: avoid page allocation beyond i_size on read

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

Re: [PATCH] mm, fs: avoid page allocation beyond i_size on read

On Wed, 21 Aug 2013 17:42:12 +0100 Steven Whitehouse 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

Re: [PATCH] mm, fs: avoid page allocation beyond i_size on read

Hi, On Wed, 2013-08-21 at 19:08 +0300, Kirill A. Shutemov wrote: > 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

Re: [PATCH] mm, fs: avoid page allocation beyond i_size on read

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

Re: [PATCH] mm, fs: avoid page allocation beyond i_size on read

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

[PATCH] mm, fs: avoid page allocation beyond i_size on read

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.

[PATCH] mm, fs: avoid page allocation beyond i_size on read

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.

Re: [PATCH] mm, fs: avoid page allocation beyond i_size on read

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

Re: [PATCH] mm, fs: avoid page allocation beyond i_size on read

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

Re: [PATCH] mm, fs: avoid page allocation beyond i_size on read

Hi, On Wed, 2013-08-21 at 19:08 +0300, Kirill A. Shutemov wrote: 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): $

Re: [PATCH] mm, fs: avoid page allocation beyond i_size on read

On Wed, 21 Aug 2013 17:42:12 +0100 Steven Whitehouse swhit...@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.