lkml.org 
[lkml]   [2004]   [Mar]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] Drop O_LARGEFILE from F_GETFL for POSIX compliance
Andi Kleen <ak@suse.de> wrote:
>
>
> On 64bit architectures open() sets O_LARGEFILE implicitely. This causes the LSB
> testsuite to fail, which checks that F_GETFL only returns the flags set by
> a previous open.
>
> According to the POSIX standards gurus the Linux behaviour is not compliant.
>
> This patch fixes this by just not reporting O_LARGEFILE in F_GETFL.
>
> This has been in several shipping SuSE releases and the x86-64.org CVS
> treee for a long time, so is unlikely to break anything.
>
> -Andi
>
> diff -burpN -X ../KDIFX linux-2.4.26-pre5/fs/fcntl.c linux-merge/fs/fcntl.c
> --- linux-2.4.26-pre5/fs/fcntl.c 2004-01-13 10:29:17.000000000 +0100
> +++ linux-merge/fs/fcntl.c 2003-10-23 15:40:52.000000000 +0200
> @@ -271,7 +271,7 @@ static long do_fcntl(unsigned int fd, un
> set_close_on_exec(fd, arg&1);
> break;
> case F_GETFL:
> - err = filp->f_flags;
> + err = filp->f_flags & ~O_LARGEFILE;
> break;
> case F_SETFL:
> lock_kernel();

eh? If the application on a 64-bit box does

open("foo", O_LARGEFILE|O_RDWR);

then a subsequent F_GETFL will now return just O_RDWR, will it not? So
it's still posixly incorrect?

I think open() needs to set O_KERNEL_LARGEFILE, and we mask that off in
F_GETFL, and test for (O_LARGEFILE|O_KERNEL_LARGEFILE) everywhere.

-
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/

\
 
 \ /
  Last update: 2005-03-22 14:01    [W:0.062 / U:0.228 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site