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

["Taylor R Campbell via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR kern/57504; it has been noted by GNATS.

From: Taylor R Campbell <riastradh%NetBSD.org@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: kre%netbsd.org@localhost, gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost
Subject: Re: PR/57504 CVS commit: src/sys/kern
Date: Fri, 18 Oct 2024 13:42:07 +0000

 > 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.