* Re: [PATCH] fcntl returns wrong error code
@ 2002-03-26 23:50 Andries.Brouwer
0 siblings, 0 replies; 4+ messages in thread
From: Andries.Brouwer @ 2002-03-26 23:50 UTC (permalink / raw)
To: alan, cyeoh; +Cc: linux-kernel, marcelo, torvalds, trivial
> When fcntl(fd, F_DUPFD, b) is called where 'b' is greater than the
> maximum allowable value EINVAL should be returned. From POSIX:
>
> "[EINVAL] The cmd argument is invalid, or the cmd argument is F_DUPFD and
> arg is negative or greater than or equal to {OPEN_MAX}, or ..."
... Also we sort of have a problem since OPEN_MAX is not
a constant on Linux x86. I guess that means a libc enforced
behaviour or something for that bit
OPEN_MAX is described in the <limits.h> POSIX man page
as a runtime invariant constant. However, it is allowed
to be indeterminate, so no problems arise, I think.
Andries
^ permalink raw reply [flat|nested] 4+ messages in thread* [PATCH] fcntl returns wrong error code
@ 2002-03-21 6:09 Christopher Yeoh
2002-03-21 13:28 ` Alan Cox
0 siblings, 1 reply; 4+ messages in thread
From: Christopher Yeoh @ 2002-03-21 6:09 UTC (permalink / raw)
To: Linus Torvalds, Marcelo Tosatti; +Cc: linux-kernel, trivial
When fcntl(fd, F_DUPFD, b) is called where 'b' is greater than the
maximum allowable value EINVAL should be returned. From POSIX:
"[EINVAL] The cmd argument is invalid, or the cmd argument is F_DUPFD and
arg is negative or greater than or equal to {OPEN_MAX}, or ..."
Currently we instead return EMFILE. The following patch (against
2.4.19pre-4) fixes this behaviour:
--- linux-2.4.18/fs/fcntl.c~ Mon Sep 24 05:13:11 2001
+++ linux-2.4.18/fs/fcntl.c Thu Mar 21 16:50:06 2002
@@ -120,8 +120,13 @@
int ret;
ret = locate_fd(files, file, start);
- if (ret < 0)
+ if (ret < 0) {
+ /* We should return EINVAL instead of EMFILE if the
+ request for the fd starts beyond the valid range */
+ if (ret==-EMFILE && start>=current->rlim[RLIMIT_NOFILE].rlim_cur)
+ ret = -EINVAL;
goto out_putf;
+ }
allocate_fd(files, file, ret);
return ret;
Chris.
--
cyeoh@au.ibm.com
IBM OzLabs Linux Development Group
Canberra, Australia
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [PATCH] fcntl returns wrong error code
2002-03-21 6:09 Christopher Yeoh
@ 2002-03-21 13:28 ` Alan Cox
2002-03-21 13:58 ` Christopher Yeoh
0 siblings, 1 reply; 4+ messages in thread
From: Alan Cox @ 2002-03-21 13:28 UTC (permalink / raw)
To: Christopher Yeoh; +Cc: Linus Torvalds, Marcelo Tosatti, linux-kernel, trivial
> When fcntl(fd, F_DUPFD, b) is called where 'b' is greater than the
> maximum allowable value EINVAL should be returned. From POSIX:
>
> "[EINVAL] The cmd argument is invalid, or the cmd argument is F_DUPFD and
> arg is negative or greater than or equal to {OPEN_MAX}, or ..."
Where does it mention rlimit ? Also we sort of have a problem since
OPEN_MAX is not a constant on Linux x86. I guess that means a libc enforced
behaviour or something for that bit
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [PATCH] fcntl returns wrong error code
2002-03-21 13:28 ` Alan Cox
@ 2002-03-21 13:58 ` Christopher Yeoh
0 siblings, 0 replies; 4+ messages in thread
From: Christopher Yeoh @ 2002-03-21 13:58 UTC (permalink / raw)
To: Alan Cox; +Cc: Linus Torvalds, Marcelo Tosatti, linux-kernel, trivial
At 2002/3/21 13:28+0000 Alan Cox writes:
> > When fcntl(fd, F_DUPFD, b) is called where 'b' is greater than the
> > maximum allowable value EINVAL should be returned. From POSIX:
> >
> > "[EINVAL] The cmd argument is invalid, or the cmd argument is F_DUPFD and
> > arg is negative or greater than or equal to {OPEN_MAX}, or ..."
>
> Where does it mention rlimit ? Also we sort of have a problem since
> OPEN_MAX is not a constant on Linux x86. I guess that means a libc enforced
> behaviour or something for that bit
In this case OPEN_MAX is defined as:
"3.167 File descriptor
A per-process unique, non negative integer used to identify an open
file for the purpose of file access. The value of a file descriptor
is from zero to {OPEN_MAX}. A process can have no more than {OPEN_MAX} file
descriptors open simultaneously. File descriptors may also be used ...."
Also from the limit.h page in Headers section it mentions that "many
of the listed limits are not invariant, and at runtime, the value of
the limit may differ from those given in the header ..... <snip> ..
.. For these reasons an application may use the fpathconf(),
pathconf() and sysconf() functions to determine the actual value of a
limit at runtime."
So the standard does take into account that the value may not be
constant and (I think) that in the fcntl case the OPEN_MAX refers to
the actual runtime value, which is not necessarily the same as the
definition in limits.h.
This problem was picked up by the POSIX.1-1990 test suite which
does a sysconf(_SC_OPEN_MAX) to determine OPEN_MAX.
btw Stephen Rothwell pointed out that there is a much neater way to
achieve the same change. I'll post a new patch in the morning.
Chris
--
cyeoh@au.ibm.com
IBM OzLabs Linux Development Group
Canberra, Australia
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2002-03-26 23:52 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-03-26 23:50 [PATCH] fcntl returns wrong error code Andries.Brouwer
-- strict thread matches above, loose matches on Subject: below --
2002-03-21 6:09 Christopher Yeoh
2002-03-21 13:28 ` Alan Cox
2002-03-21 13:58 ` Christopher Yeoh
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®