From mboxrd@z Thu Jan 1 00:00:00 1970 From: Theodore Ts'o Subject: Re: [RFC PATCH 1/2] VFS: Kill use of O_LARGEFILE inside the kernel Date: Tue, 22 Sep 2015 15:25:27 -0400 Message-ID: <20150922192527.GA3318@thunk.org> References: <20150922155104.GA2296@thunk.org> <20150922152450.32539.55285.stgit@warthog.procyon.org.uk> <1458.1442938362@warthog.procyon.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com, viro@zeniv.linux.org.uk, linux-kernel@vger.kernel.org To: David Howells Return-path: Content-Disposition: inline In-Reply-To: <1458.1442938362@warthog.procyon.org.uk> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: xfs-bounces@oss.sgi.com Sender: xfs-bounces@oss.sgi.com List-Id: linux-fsdevel.vger.kernel.org On Tue, Sep 22, 2015 at 05:12:42PM +0100, David Howells wrote: > > Further, path-based truncate() makes no checks based on file-largeness, unlike > ftruncate(). Right, but truncate in general is used to make files *smaller* so I'm having trouble thinking of a scenario where a largefile-oblivious program could get in trouble by truncating a file > 2TB to some hard-coded length (normally zero). > Overlayfs and one or two other places need to potentially apply O_LARGEFILE to > the things that they do on behalf of userspace - but other than suppressing > some size checks, it seems to be ignored by the filesystems and the VM. The size checks really were the primary points of O_LARGEFILE. As I recall the primary system calls where this really matters is open(2) and stat(2) (since if st_size is too small to represent the size of the file, then the user space program could get really confused). Essentially O_LARGEFILE is an assertion that userspace can handle handle 64-bit files, and won't get confused by system call interfaces where off_t is 32-bit wide, because it will use the 64-bit variants. So it's not at all surprising that the file systems and the VM in general doesn't need to worry about the flag. - Ted _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs