Re: kern/54435: reading TCP urgent data with MSG_OOB doesn't clear poll(2) status

[mlelstv%serpens.de@localhost (Michael van Elst)]

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

From: mlelstv%serpens.de@localhost (Michael van Elst)
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: kern/54435: reading TCP urgent data with MSG_OOB doesn't clear poll(2) status
Date: Sun, 4 Aug 2019 04:36:55 -0000 (UTC)

 uwe%stderr.spb.ru@localhost (Valery Ushakov) writes:
 
 > Right, right.  That is exactly what fails.  SIOCATMARK in that code
 > just makes sure we read oob "in-band", but the failed output already
 > was doing it if by chance.  If I modify the test to actually sync the
 > oob byte position with SIOCATMARK it fails just the same.
 
 If you change the test to
 - read OOB data when you get (POLLPRI | POLLRDBAND)
 - read regular data when you get POLLIN
 - do both when you get both conditions
 
 then
 
 % ./oobrecv oob delay sync
 reading urgent data with MSG_OOB with SIOCATMARK after delay
 poll: revents = 0x83: IN PRI RDBAND
 recv() = 1 (reading to mark)
 a
 <at mark>
 recv(MSG_OOB) = 1
 b
 recv() = 1
 c
 poll: revents = 0x1: IN
 recv() = 0
 
 
 If anyone would actually use urgent data, we would probably
 have a different interface. Then we wouldn't be limited to
 a single byte either. TCP after all doesn't impose such
 a limit.
 
 
 -- 
 -- 
                                 Michael van Elst
 Internet: mlelstv%serpens.de@localhost
                                 "A potential Snark may lurk in every tree."