> > > Readable and doesn't waste kernel memory.
> > Just user space code bloat....
> 
> No - during the poll, kernel allocates memory for array to hold
> all the poll structs userland has passed via poll(2) call. Also,
> the bigger the array the more time is spent copying structs from
> userland to kernel, especially if you watch many descriptors and
> call poll(2) frequently.

You will find that the cost of that code section is irrelevant
provided the supplied array isn't stupidly spare.
It is even possible that a copyin() loop is faster that the malloc()
case for calls with nfds > 32 until you get to VERY large numbers
(where the fact that you have to read the array twice becomes
relevant).  But I don't want to do that benchmark!

> > The SuS says that EINVAL should be returned if the 'nfds' argument
> > is greater than OPEN_MAX.
> 
> OPEN_MAX is fixed @ 64 (see <sys/syslimits.h>)

RTFM, it is a 'variable' constant and the run time value can
be different from the compile time one.
sysconf( _SC_OPEN_MAX ) could even return -1 implying that there
is no appropriate limit.  After all setrlimit() could increase
it indefinitely.

> > (There should be a check in setrlimit to ensure that
> > p->p_rlimit[RLIMIT_NOFILE].rlim_cur > p->p_fd->fd_lastfile)
> 
> I don't think so. There isn't anything wrong in setting NOFILE
> to lower value than current use; that would just prevent to open
> any new files until some descriptors are closed.

Erm, both netbsd and the SuS have:
     The setrlimit() function may fail if:

    [EINVAL]	The limit specified to setrlimit() cannot be lowered, be-
		cause current usage is already higher than the limit.

This would be useful because it would let a program determine
a (sensible) upper bound for the highest open fd.
This is a number that certain processes need to know (eg in order
to close all high numbered fds) but is impossible to determine.
Typically rlimit(NO_FILES) is used - causing a lot of failed close()
calls if it is set very high.

Given that some programs close all high numbered fds, I'm sure
there is a lurking security issue if you set rlimit(NO_FILES)
to below one of their open files - since it won't get closed.
OTOH I haven't spotted anything useful (yet).

	David

-- 
David Laight: david@l8s.co.uk