The select(2) family of syscalls was designed to work this way (block when
file descriptors are not available, even when they cannot become available).
For example:
select(0, NULL, NULL, NULL, NULL);
blocks forever.
In fact in the very old days (before usleep, nanosleep,
On Wed, 01 Apr 2020 13:53:53 +0200, Claudio Jeker wrote:
> I think this is actually a feature. The standard does not mention that you
> have to listen on something and it would allow to use select() as a
> sleep() replacement. I would expect that pselect() should behave the same
> way.
I agree
The regress test is wrong.
The first parameter to pselect has to tell it which bits to look at.
It should be something like getdtablesize(), or fd+1, or FD_SETSIZE.
And then there's all the handwaving about fd_set overflow, meaning what
if fd >= FD_SETSIZE. I've never heard of an exploitable
On Wed, Apr 01, 2020 at 01:08:10PM +0200, Martin Pieuchot wrote:
> While working on moving pselect(2) outside of the KERNEL_LOCK() I found
> this surprising {p,}select(2) behavior exposed by the libc/sys/t_select.c
> regression test. Should it be considered as a bug or feature?
I think this is
While working on moving pselect(2) outside of the KERNEL_LOCK() I found
this surprising {p,}select(2) behavior exposed by the libc/sys/t_select.c
regression test. Should it be considered as a bug or feature?
The above mentioned test does the following (simplified):
fd =
