Messages in this thread | | | From | David Howells <> | Subject | Re: [RFC PATCH 1/2] VFS: Kill use of O_LARGEFILE inside the kernel | Date | Tue, 22 Sep 2015 17:12:42 +0100 |
| |
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
| |