Re: process file descriptor limit handling

[Chris Wright <chrisw@osdl.org>]

* Ulrich Drepper (drepper@redhat.com) 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