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: Thu, 8 Aug 2019 01:29:14 +0300

 On Mon, Aug 05, 2019 at 09:25:02 +0000, Michael van Elst wrote:
 
 >  ... getting POLLPRI _after_ you can read OOB data isn't that
 >  different.  It's even possible that OOB data gets lost if multiple
 >  chunks exist.
 
 That still makes absolutely no sense to me.  The kernel knows whether
 there is or there is no more OOB data, doesn't it?  Yes, it's
 technically correct ("the best kind of correct") to return POLLPRI b/c
 MSG_OOB never blocks, but it's useless and harmful.
 
 Yes, reading past the mark would have cleared it (at least for TCP,
 where urgent data are not really out of band), but what if there's no
 normal data to read?
 
 Change the test to
 
     send("a")
     send("B", MSG_OOB)
     /* ride into the sunset */
 
 our current behaviour just spams the reader with POLLPRI causing it to
 get stuck in busy-wait:
 
   reading urgent data with MSG_OOB with SIOCATMARK
 
   poll: revents = 0x1: IN
   recv() = 1
   a
 
   poll: revents = 0x82: PRI RDBAND
   <at mark>
   recv(MSG_OOB) = 1
   B
 
   poll: revents = 0x82: PRI RDBAND
   <at mark>
   oobrecv: recv(MSG_OOB): Invalid argument
 
   poll: revents = 0x82: PRI RDBAND
   <at mark>
   oobrecv: recv(MSG_OOB): Invalid argument
 
   poll: revents = 0x82: PRI RDBAND
   <at mark>
   oobrecv: recv(MSG_OOB): Invalid argument
   ...
 
 which is obviously bad.  Solaris that probably copied that code from
 BSD has the same problem.
 
 
 >  This is not a good interface, just an attempt to get OOB and urgent
 >  data accessible to userland. It doesn't have to "make sense" and
 >  changing just a small aspect of it probably does more harm than
 >  keeping the established behaviour, in particular when there is
 >  almost no user of that interface.
 
 We may call it an "established behaviour" or we may call it a buggy
 corner case that was never properly tested, in particular *because*
 "there is almost no users of that interface".  rlogin that kre@
 mentioned seems to be the only user of recv(MSG_OOB) in our tree and
 it doesn't even use poll/select, it uses SIGURG.
 
 Yes, poll behaviour (as in which events are reported when) varies
 (sometimes *wildly*) between different systems (cf. things like
 POLLHUP for half-closed TCP connections) and changing it can break
 code that was written to assume that specific behaviour, but in this
 case the stars are algined.  There's probably no existing callers at
 all and our existing behaviour easily causes a busy loop with POLLPRI
 spam.  Linux behaviour in this area makese sense and is useful, so I
 don't see why we don't adopt it.
 
 -uwe