Re: PR/57504 CVS commit: src/sys/kern

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

> Date: Fri, 18 Oct 2024 13:12:34 +0000
> From: "Robert Elz" <kre%netbsd.org@localhost>
> 
> This should have zero impact on any sane application which
> uses the highest fd for which it set a bit, +1, as the first
> arg to select.   However, if there are any broken applications
> that were relying upon the previous behaviour of simply ignoring
> any fd_masks that started beyond the max number of open files,
> then they might (if they happen to have any bits set) now fail.

I think this came up in a real application, but it's been long enough
that I forget which one, and unfortunately I neglected to record it in
the original PR (if it was a real application and not just code
inspection on my part).

Some real applications might not keep track of the highest fd they set
in the fd_set, and just keep track of the highest fd they have ever
allocated seen, or just pass FD_SETSIZE.

> XXX pullup -10 -- but not for a long time.  Someone remind me
>     sometime next year.  Leave a long settling time in HEAD just to
>     be sure no issues arise, as in practice, almost nothing should
>     cause any of the new code to be executed.
> 
>     pullup -9 -- probably not, what this fixes isn't significant
>     enough to bother going that far back for (IMO).

Surely we should have an automatic test in atf for this so can verify
it has been fixed in pullup too?

I think a fix for this bug is also worth pulling up to 9 -- basic
central functionality like select should be reliable, not spuriously
hang in weird circumstances.