openssh unix dev - Jan 2022 - OS X poll breakage (Was: Please help test recent changes)

On 1/11/22 02:30, Damien Miller wrote:
> On Tue, 11 Jan 2022, Damien Miller wrote:
> 
>> Here's the client side log of the failure. It comes from the
>> "same with early close of stdout/err" section of the test,
but I can't
>> actually see anything get closed...
>>
>> debug3: receive packet: type 91
>> debug2: channel_input_open_confirmation: channel 0: callback start
>> debug2: client_session2_setup: id 0
>> debug1: Sending command: exec sh -c 'sleep 2; exec > /dev/null
2>&1; sleep 3; exit 0'
>> debug2: channel 0: request exec confirm 1
>> debug3: send packet: type 98
>> debug2: channel_input_open_confirmation: channel 0: callback done
>> debug2: channel 0: open confirm rwindow 0 rmax 32768
>> debug2: channel 0: rcvd adjust 2097152
>> debug3: receive packet: type 99
>> debug2: channel_input_status_confirm: type 99 id 0
>> debug2: exec request accepted on channel 0
>> channel 0: invalid rfd pollfd[2].fd 4 r4 w7 e8 s-1
>>
>> and (separate run) with DEBUG_CHANNEL_POLL set:
>>
>> debug2: channel_input_status_confirm: type 99 id 0
>> debug2: exec request accepted on channel 0
>> debug3: dump_channel_poll: channel 0: rfd r4 w7 e8 s-1 pfd[2].fd=4 want
0x01 ev 0x01 ready 0x00 rev 0x00
>> debug3: dump_channel_poll: channel 0: rfd r4 w7 e8 s-1 pfd[3].fd=7 want
0x01 ev 0x00 ready 0x00 rev 0x00
>> debug3: dump_channel_poll: channel 0: rfd r4 w7 e8 s-1 pfd[4].fd=8 want
0x01 ev 0x00 ready 0x00 rev 0x00
>> debug1: channel_after_poll: pfd[2].fd 4 rev 0x0020
>> debug3: dump_channel_poll: channel 0: rfd r4 w7 e8 s-1 pfd[2].fd=4 want
0x01 ev 0x01 ready 0x00 rev 0x20
>> channel 0: invalid rfd pollfd[2].fd 4 r4 w7 e8 s-1
>> FAIL: exit code (with sleep) mismatch for: 255 != 0
>>
>> It looks like it fails with HAVE_POLL set to 0 too.
>>
>> Still looking...
> 
> Wow, it looks like Darwin's poll(2) is completely broken for character-
> special devices (at least). E.g. the attached program spins shows similar
> behaviour when run on /dev/null - it spins, returning revents=POLLNVAL.
Is using kqueue(2) an option?  That?s faster, and it doesn?t have the
problem with large file descriptors that poll(2) has.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0xB288B55FFF9C22C1.asc
Type: application/pgp-keys
Size: 4885 bytes
Desc: OpenPGP public key
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20220111/45651b0b/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20220111/45651b0b/attachment.asc>

On Tue, 11 Jan 2022, Demi Marie Obenour wrote:
> Is using kqueue(2) an option?
The linked-to post says that there?s an open Apple bug that
both poll(2) and kqueue(2) on anything in /dev/ are broken.

bye,
//mirabilos
-- 
Infrastrukturexperte ? tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn ? http://www.tarent.de/
Telephon +49 228 54881-393 ? Fax: +49 228 54881-235
HRB AG Bonn 5168 ? USt-ID (VAT): DE122264941
Gesch?ftsf?hrer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

                        ****************************************************
/?\ The UTF-8 Ribbon
??? Campaign against      Mit dem tarent-Newsletter nichts mehr verpassen:
??? HTML eMail! Also,     https://www.tarent.de/newsletter
??? header encryption!
                        ****************************************************

On Tue, 11 Jan 2022, Demi Marie Obenour wrote:
> > Wow, it looks like Darwin's poll(2) is completely broken for
> > character- special devices (at least). E.g. the attached program
> > spins shows similar behaviour when run on /dev/null - it spins,
> > returning revents=POLLNVAL.
>
> Is using kqueue(2) an option? That?s faster, and it doesn?t have the
> problem with large file descriptors that poll(2) has.
No, because it's not cross-platform and I don't want to have to maintain
multiple mainloops (believe me, one is more than enough). It would have
been really nice if the OSS Unix-like operating systems has standardised
on one event notification; kqueue and epoll are both fine.

Also, it seems like the OS X kqueue(2) implementation suffers from the
same bug anyway. I suspect that this is the root cause, and that their
poll(2) is built on top of kqueue(2).

-d