[PATCH] fcntl returns wrong error code

[PATCH] fcntl returns wrong error code

[Christopher Yeoh]

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

Re: [PATCH] fcntl returns wrong error code

[Alan Cox]

> 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

Re: [PATCH] fcntl returns wrong error code

[Christopher Yeoh]

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

Re: [PATCH] fcntl returns wrong error code (Updated)

[Christopher Yeoh]

At 2002/3/22 00:58+1100  Christopher Yeoh writes:
> 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.

This is the updated patch.

--- linux-2.4.18/fs/fcntl.c~	Fri Mar 22 11:54:35 2002
+++ linux-2.4.18/fs/fcntl.c	Fri Mar 22 12:31:18 2002
@@ -66,6 +66,10 @@
 
 	write_lock(&files->file_lock);
 	
+	error = -EINVAL;
+	if (orig_start >= current->rlim[RLIMIT_NOFILE].rlim_cur)
+		goto out;
+
 repeat:
 	/*
 	 * Someone might have closed fd's in the range