From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758699AbbIVTZd (ORCPT ); Tue, 22 Sep 2015 15:25:33 -0400 Received: from imap.thunk.org ([74.207.234.97]:37154 "EHLO imap.thunk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756355AbbIVTZb (ORCPT ); Tue, 22 Sep 2015 15:25:31 -0400 Date: Tue, 22 Sep 2015 15:25:27 -0400 From: "Theodore Ts'o" To: David Howells Cc: viro@zeniv.linux.org.uk, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: [RFC PATCH 1/2] VFS: Kill use of O_LARGEFILE inside the kernel Message-ID: <20150922192527.GA3318@thunk.org> Mail-Followup-To: Theodore Ts'o , David Howells , viro@zeniv.linux.org.uk, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, xfs@oss.sgi.com 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-Disposition: inline In-Reply-To: <1458.1442938362@warthog.procyon.org.uk> User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@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