compat tasks and O_LARGEFILE
This code sequence in linux/fs/open.c:
Quoted 8 lines
asmlinkage long
sys_open(const char __user * filename, int flags, int mode){ char * tmp; int fd, error;#if BITS_PER_LONG != 32 flags |= O_LARGEFILE;#endif
is problematic for compat tasks. For eg: negative seeks can result in ~4GB files getting created.
Are there any objections to letting a task reset this flag using a fcntl? There are some corner cases, such as what if the file pointer is already beyond 4GB etc, but I think they're solvable.
-Arun
Quoted 1 line · On Fri, 27 Feb 2004 17:57:09 -0800 Arun Sharma <[email protected]> wrote:
This code sequence in
linux/fs/open.c:
...
Quoted 10 lines
Quoted 3 lines
#if BITS_PER_LONG != 32 flags |= O_LARGEFILE;#endif
is problematic for compat tasks. For eg: negative seeks can result in ~4GB files getting created.
Are there any objections to letting a task reset this flag using a fcntl? There are some corner cases, such as what if the file pointer is already beyond 4GB etc, but I think they're solvable.
See arch/sparc64/kernel/sys_sparc32.c:sparc32_open(), old and known issue. That piece of code belongs in fs/compat.c so that it isn't duplicated all over.
Quoted 4 lines · David S. Miller
See arch/sparc64/kernel/sys_sparc32.c:sparc32_open(), old and known issue. That piece of code belongs in
fs/compat.cso that it isn't duplicated all over.
This approach doesn't work for completely user level 32 bit emulation. One example is IA-32 EL:
http://www.intel.com/pressroom/archive/releases/20040113comp.htm
[ The Linux version is in the pipeline ]
There's also something in POSIX that requires user level access to such bits via a fcntl. I don't have the spec handy right now...
-Arun
Quoted 1 line · On Sat, 28 Feb 2004 18:38:02 -0800 Arun Sharma <[email protected]> wrote:
This approach doesn't work for completely user level 32 bit emulation.
If the emulation is completely user level, then you're asking to modify the 64-bit syscall behavior, and that's more of a linux-kernel topic probably?