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 22:07:39 +0300

 On Sun, Aug 04, 2019 at 04:40:01 +0000, Michael van Elst wrote:
 
 >  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
 
 So far so good.
 
 
 >  recv() = 1
 >  c
 >  poll: revents = 0x1: IN
 >  recv() = 0
 
 But this is cheating :) You continue reading from the socket which
 does succeed and which clears POLLPRI.  The bug I'm reporting is
 exactly that if you poll the socket in this state you will get POLLPRI
 even though there is no urgent/oob data.
 
 
 -uwe