Re: [LTP] Suggested patch to recvfrom / recvmsg tests

[chrubis@suse.cz]

Hi!
> > What arch is this?
> 
> Irrelevant, I think, but x86_64.

Sorry the question was not specific enough I should have asked for
distribution and architecture. But the paragraph below explains why you
system is different.

> > On my system both getfdsetsize() and FD_SETSIZE are set to 1024?
> 
> The test uses getdtablesize(), which pulls the OPEN_MAX kernel parameter.
> In our kernel, we have OPEN_MAX set to more than FD_SETSIZE.
> 
> I first found this problem when this parameter had a typo, adding an order of magnitude to OPEN_MAX.
> Without the added clause in the loop to restrict it, the test would usually core from zero-bit bombardment into related memory. 
> Correcting the parameter typo unfortunately did not alter the test binary's behavior.
> 
> Arguably, this might be a bug with /usr/include/x86_64-linux-gnu/bits/typesizes.h and /usr/include/linux/posix_types.h
> which hard-code __FD_SETSIZE to 1024 instead of checking the OPEN_MAX kernel paramenter.
> (My knee-jerk reaction is to file this alongside "select() is broken".  :-)

Well, select() is decades old interface and fd_set was designed as fixed
size buffer back then, I would say that it's broken by design, because
if you open more filedescriptors than was __FD_SETSIZE by the time of
the program compilation it will break anyway. Happily we have poll() and
epoll() for programs that need to use more than 1024 file descriptors.

> An alternative patch might be to replace the getdtablesize() call by getfdsetsize().
> This would rely on accept() never returning a value greater than FD_SETSIZE.

That will not happen in this case, see below.

> I see no indication in accept, select, or poll manpages whether this is the case;
> I suspect it is so, otherwise select/poll cannot detect activity on some range of returned fd.

Well filedescriptors are allocated from lowest available number, so
everything works fine unless you keep open more than 1022 file
descriptors (first three are allocated for stdin, stdout and stderr).

> This would require inspecting the accept() code, though, and adding a test on accept() to verify that accept() cannot return a fd greater than FD_SETSIZE.
> Maybe accept() in a near-infinite loop to exhaust all fd's ...?
> (Beyond my available time right now.)
> 
> 
> > What about we set nfds to sfd + 1 and for each child we accept we set nfds to max(nfds, newfd+1)?
> 
> When accept() returns the highest-select()-detectable fd, this will clear the high-bit just off the end of the fdset, would it not?
> It'll hit far less often, but still be out-of-bounds, sadly ....

Looking at the code, the newly opened filedescriptor is closed right
away. I've tried to add printf() to the code and indeed it's always se
to 4, so the maximum would end up as 5.

-- 
Cyril Hrubis
chrubis@suse.cz

------------------------------------------------------------------------------
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list