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: Robert Elz <kre%munnari.OZ.AU@localhost>
Subject: Re: kern/54435: reading TCP urgent data with MSG_OOB doesn't clear
 poll(2) status
Date: Thu, 8 Aug 2019 04:21:46 +0300

 On Thu, Aug 08, 2019 at 00:35:01 +0000, Robert Elz wrote:
 
 >    | And since we do provide recv(MSG_OOB) we might as well provide
 >    | non-buggy poll to go with it.
 >  
 >  Again, Michael says that what we have isn't buggy.   From the example in
 >  the tutorial (which remains in rlogin to this day) the method used for
 >  urgent data using recv(MSG_OOB) is to read (using recv() or read()) until
 >  SOICATMARK returns true, and then do the recv(MSG_OOB).   Have you tried
 >  that to see if that works?   It is not what your test program did.
 
 See my previous reply to the PR.  If the sender sends
 
     send("a")
     send("B", MSG_OOB)
     /* stops sending, keeps connection open */
 
 and the receiver
 
     recv until SIOCATMARK -> "a"
     recv(MSG_OOB) -> "B"
 
 and then calls poll with POLLIN|POLLPRI to decide what to do next, it
 will end up in an busy-wait loop as poll will immediately return
 POLLPRI (only), but recv(MSG_OOB) will fail, then the receiver calls
 poll and the loop repeats.
 
 
 Aside - I wonder if the notion of "at mark" made sense for those other
 protocols that had real out of band data (of which I know nothing).
 
 It's also not entirely obvious to me what given POLLIN | POLLRDBAND
 the right action is to read/drain the normal (in band) stream first.
 This is likely highly application and protocol dependent, but it would
 seem natural to want to read real out of band data out of band,
 i.e. calling recv(MSG_OOB) as soon as POLLRDBAND is reported.  So I'm
 somewhat worried that we are imposing the semantic of TCP not-really
 OOB urgent data - which happens to be the only user of this interface
 - on the way that interface behaves.
 
 
 >  I also asked (earlier) what FreeBSD/MacOS/Solaris do in this area - that
 >  linux is different would not be all that strange.  It often is.
 
 As I noted in the previous reply Solaris seems to behave the same,
 with POLLPRI spammed after the urgent data has been read.  I'm
 travelling, so I don't have a macos system handy.  I'll test when I
 get back home.
 
 
 -uwe