* compat tasks and O_LARGEFILE
@ 2004-02-28 1:57 Arun Sharma
2004-02-28 23:56 ` David S. Miller
0 siblings, 1 reply; 4+ messages in thread
From: Arun Sharma @ 2004-02-28 1:57 UTC (permalink / raw)
To: linux-arch
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: compat tasks and O_LARGEFILE
2004-02-28 1:57 compat tasks and O_LARGEFILE Arun Sharma
@ 2004-02-28 23:56 ` David S. Miller
2004-02-29 2:38 ` Arun Sharma
0 siblings, 1 reply; 4+ messages in thread
From: David S. Miller @ 2004-02-28 23:56 UTC (permalink / raw)
To: Arun Sharma; +Cc: linux-arch
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.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: compat tasks and O_LARGEFILE
2004-02-28 23:56 ` David S. Miller
@ 2004-02-29 2:38 ` Arun Sharma
2004-03-01 5:56 ` David S. Miller
0 siblings, 1 reply; 4+ messages in thread
From: Arun Sharma @ 2004-02-29 2:38 UTC (permalink / raw)
To: David S. Miller; +Cc: linux-arch
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: compat tasks and O_LARGEFILE
2004-02-29 2:38 ` Arun Sharma
@ 2004-03-01 5:56 ` David S. Miller
0 siblings, 0 replies; 4+ messages in thread
From: David S. Miller @ 2004-03-01 5:56 UTC (permalink / raw)
To: Arun Sharma; +Cc: linux-arch
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?
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2004-03-01 5:56 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-02-28 1:57 compat tasks and O_LARGEFILE Arun Sharma
2004-02-28 23:56 ` David S. Miller
2004-02-29 2:38 ` Arun Sharma
2004-03-01 5:56 ` David S. Miller
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.