Re: CVS commit: src/sys/kern

[David Laight <david%l8s.co.uk@localhost>]

On Mon, Dec 14, 2009 at 10:12:24PM +0000, Mindaugas Rasiukevicius wrote:
> Hello,
> 
> > Module Name:    src
> > Committed By:   dsl
> > Date:           Sat Dec 12 17:47:05 UTC 2009
> > 
> > Modified Files:
> >         src/sys/kern: sys_select.c
> > 
> > Log Message:
> > Bounding the 'nfds' arg to poll() at the current process limit for actual
> > open files is rather gross - the poll map isn't required to be dense.
> > Instead limit to a much larger value (1000 + dt_nfiles) so that user
> > programs cannot allocate indefinite sized blocks of kvm.
> 
> This does not look right to me.
> 
> - Where does the random value 1000 come from?  If you need a limit, POSIX
>   allows to limit up to OPEN_MAX (thus did SVR4?).
> 
> - How about truncating to fd_lastfile (plus one), instead of dt_nfiles?

Both fd_lastfile and dt_nfiles are bounds on the current number of
open files.  Since there is no requirement for the poll list to be
dense (or even only hold each fd once!) never mind be indexed by fd
number, any such limit is doomed to failure when programs use any
other scheme for indexing the poll list.

The only real solution is to process the user-supplied buffer in chunks.
But that is a lot of code that would very rarely be used.

Using OPEN_MAX isn't really a solution - you need the dynamic value, so
rlimit.nofiles is the only possible value - but the process can have
more fd's open than the current rlimit value.

Since the only reason for a limit is to avoid programs using all KVM
just bounding 'nfds' to some number significantly larger than any
normal program would use seemed enough to stop any programs failing.
And yes 1000 is just a random number!

I actually suspect that most failures are only be a few fd - where the
application is reserving a few low-numbered slots for specific uses.

        David

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