* Ulrich Drepper ([EMAIL PROTECTED]) wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> The current kernel (and all before as far as I can see) have a problem
> with the file system limit handling. The behavior does not conform to
> the current POSIX spec.
<snip>
> It might also be that some wording is getting in the specification which
> will allow the current kernel behavior to continue to exist. More
> through a loophole, but still.
This seems the case. SuS v3 says:
setrlimit
RLIMIT_NOFILE
This is a number one greater than the maximum value that the system
may assign to a newly-created descriptor. If this limit is exceeded,
functions that allocate a file descriptor shall fail with errno set
to [EMFILE]. This limit constrains the number of file descriptors
that a process may allocate.
open
[EMFILE]
{OPEN_MAX} file descriptors are currently open in the calling process.
limits.h
{OPEN_MAX}
Maximum number of files that one process can have open at any one time.
Minimum Acceptable Value: {_POSIX_OPEN_MAX}
So, one view says your test program is within the spec, since the new fd
is still one less than the current rlimit.
Anyway, here's a simple patch that would fail the second setrlimit, as you
suggested.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
