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: Sat, 3 Aug 2019 20:20:34 -0000 (UTC)

 riastradh%NetBSD.org@localhost (Taylor R Campbell) writes:
 
 > poll on a socket returns POLLPRI|POLLRDBAND as long as so->so_oobmark
 > is nonzero or so->so_state has SS_RCVATMARK is set.
 > 
 > - so_oobmark is the pointer to how many bytes away the urgent data are.
 > - SS_RCVATMARK is set when the urgent data are clamouring at the gate.
 > 
 > These are updated by normal reads, but not by the recv(MSG_OOB) call
 > that actually returns the urgent data.
 
 
 That's how it is supposed to be.
 
 OOB data is not delivered in the stream. Instead you get information
 that 'urgent data' lies ahead. recv(MSG_OOB) can be used to peek at
 that data, but it doesn't consume the stream or that data. That's
 why the poll condition persists. It's even possible that you cannot
 peek at the data, because it hasn't been received, then recv(MSG_OOB)
 is supposed to return EWOULDBLOCK.
 
 The correct answer to 'urgent data' is to consume the stream to
 the point where the OOB data lies ahead. Then, since a normal
 recv() won't deliver the urgent data to the application, use
 recv(MSG_OOB) to read it. At that point, the poll condition
 already has been cleared by reading the stream.
 
 To read ahead you can use the SIOCATMARK ioctl that returns the
 state of the RCVATMARK flag. The recv() is automatically truncated
 so that you don't read past the urgent data.
 
 An alternative to recv(MSG_OOB) is the SO_OOBINLINE option. Then you
 don't need recv(MSG_OOB) to get at the urgent data but read it
 directly. There is even an RFC telling that this behaviour was
 originally intended, but everyone copied the MSG_OOB interface.
 
 -- 
 -- 
                                 Michael van Elst
 Internet: mlelstv%serpens.de@localhost
                                 "A potential Snark may lurk in every tree."