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

[Valery Ushakov <uwe%stderr.spb.ru@localhost>]

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

From: Valery Ushakov <uwe%stderr.spb.ru@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: Michael van Elst <mlelstv%serpens.de@localhost>
Subject: Re: kern/54435: reading TCP urgent data with MSG_OOB doesn't clear
 poll(2) status
Date: Sun, 4 Aug 2019 02:20:40 +0300

 On Sat, Aug 03, 2019 at 22:15:01 +0000, Michael van Elst wrote:
 
 >  uwe%stderr.spb.ru@localhost (Valery Ushakov) writes:
 >  
 >  > Except that this is not what happens, as far as I can tell.  Consider
 >  > the output from the test quoted in the PR:
 >  
 >  Without error handling:
 [...]
 
 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.  The
 modified test does a 1s delay (to make sure the oob data is
 available), adds SIOCATMARK loop if POLLPRI is set and falls back to
 reading w/out MSG_OOB if MSG_OOB fails:
 
   $ ./oobrecv oob delay
   reading urgent data with MSG_OOB after delay
   poll: revents = 0x83: IN PRI RDBAND
   recv() = 1 (reading to mark)
   a
   at mark
   recv(MSG_OOB) = 1
   b
   poll: revents = 0x83: IN PRI RDBAND
   at mark
   recv(MSG_OOB) failed, retrying
   recv() = 1
   c
   poll: revents = 0x1: IN
   recv() = 0
 
 -uwe