compat tasks and O_LARGEFILE

compat tasks and O_LARGEFILE

[Arun Sharma]

This code sequence in linux/fs/open.c:

> 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

Re: compat tasks and O_LARGEFILE

[David S. Miller]

On Fri, 27 Feb 2004 17:57:09 -0800
Arun Sharma <arun.sharma@intel.com> wrote:

> This code sequence in linux/fs/open.c:
 ...
> > #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.

Re: compat tasks and O_LARGEFILE

[Arun Sharma]

On Sat, Feb 28, 2004 at 03:56:26PM -0800, David S. Miller wrote:
> 
> 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.

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

Re: compat tasks and O_LARGEFILE

[David S. Miller]

On Sat, 28 Feb 2004 18:38:02 -0800
Arun Sharma <arun.sharma@intel.com> 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?