linux-kernel - Re: [PATCH] mm, fs: avoid page allocation beyond i

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 21 Aug 2013 13:58:21 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Steven Whitehouse <swhiteho@...hat.com>
Cc:	"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
	Dave Hansen <dave.hansen@...ux.intel.com>,
	Jan Kara <jack@...e.cz>, Al Viro <viro@...iv.linux.org.uk>,
	NeilBrown <neilb@...e.de>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mm, fs: avoid page allocation beyond i_size on read

On Wed, 21 Aug 2013 17:42:12 +0100 Steven Whitehouse <swhiteho@...hat.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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/