Re: [RFC PATCH 1/2] VFS: Kill use of O_LARGEFILE inside the kernel

From	David Howells <dhowells@redhat.com>
Newsgroups	linux.kernel
Subject	Re: [RFC PATCH 1/2] VFS: Kill use of O_LARGEFILE inside the kernel
Date	2015-09-22 18:20 +0200
Message-ID	<qbysr-219-41@gated-at.bofh.it> (permalink)
References	<qby96-1o7-87@gated-at.bofh.it> <qbxG1-P2-3@gated-at.bofh.it> <qby96-1o7-87@gated-at.bofh.it>
Organization	Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903

Show all headers | View raw

Theodore Ts'o <tytso@mit.edu> wrote:

> So what this means is that on 32-bit systems, if we have a userspace
> program which isn't using the Largefile-enabled, and it opens a file
> which is larger than can be addressed with a 32-bit off_t, it can get
> surprised and possibly cause data loss.

Good point.  I was initially thinking that 32-bit userspace on a 64-bit system
would have O_LARGEFILE automatically enabled - but I guess it'll trap through
the compat entry points which avoid that.

That said, fanotify and xfs_open_by_handle() will both automatically set
O_LARGEFILE irrespectively of the 32-bitness of the original caller.

Further, path-based truncate() makes no checks based on file-largeness, unlike
ftruncate().

> Is this something we are willing to live with?  After all, there was a
> originally a really good reason for the O_LARGEFILE flag in the first
> place, and it was primarily about making sure that a non-LARGEFILE
> capable program would hard fail on the open, instead of after it had
> trashed the user's data.

Okay, that seems reasonable - but it still leaves truncate() dangling.  I'm
not sure there's a good answer to that, though.

> Was there a reason that motivated this change, other than just an
> clean up?

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.

I vaguely seem to remember that at one point there were still filesystems that
couldn't handle large files and would reject such opens - but they appear to
all have been fixed.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Thread

[RFC PATCH 1/2] VFS: Kill use of O_LARGEFILE inside the kernel David Howells <dhowells@redhat.com> - 2015-09-22 17:30 +0200
  Re: [RFC PATCH 1/2] VFS: Kill use of O_LARGEFILE inside the kernel Theodore Ts'o <tytso@mit.edu> - 2015-09-22 18:00 +0200
    Re: [RFC PATCH 1/2] VFS: Kill use of O_LARGEFILE inside the kernel David Howells <dhowells@redhat.com> - 2015-09-22 18:20 +0200
      Re: [RFC PATCH 1/2] VFS: Kill use of O_LARGEFILE inside the kernel Theodore Ts'o <tytso@mit.edu> - 2015-09-22 21:30 +0200
      Re: [RFC PATCH 1/2] VFS: Kill use of O_LARGEFILE inside the kernel Dave Chinner <david@fromorbit.com> - 2015-09-22 23:50 +0200

csiph-web