Subject: Re: poll(2) oddity
From: David Laight <email@example.com>
Date: 07/08/2002 13:40:49
> > > 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
> > (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 Laight: firstname.lastname@example.org