Re: [PATCH] af_unix: Allow Unix sockets to raise SIGURG

On Fri, Jan 29, 2021 at 01:18:20PM -0800, Jakub Kicinski wrote:

On Fri, 29 Jan 2021 12:44:44 -0800 Shoaib Rao wrote:

quoted

On 1/29/21 12:18 PM, Jakub Kicinski wrote:

quoted

On Fri, 29 Jan 2021 12:10:21 -0800 Shoaib Rao wrote:  

quoted

The code does not care about the size of data -- All it does is that if
MSG_OOB is set it will deliver the signal to the peer process
irrespective of the length of the data (which can be zero length). Let's
look at the code of unix_stream_sendmsg() It does the following (sent is
initialized to zero)  

Okay. Let me try again. AFAICS your code makes it so that data sent
with MSG_OOB is treated like any other data. It just sends a signal.  

Correct.

quoted

So you're hijacking the MSG_OOB to send a signal, because OOB also
sends a signal.  

Correct.

quoted

  But there is nothing OOB about the data itself.  

Correct.

quoted

  So
I'm asking you to make sure that there is no data in the message.  

Yes I can do that.

quoted

That way when someone wants _actual_ OOB data on UNIX sockets they
can implement it without breaking backwards compatibility of the
kernel uAPI.  

I see what you are trying to achieve. However it may not work.

Let's assume that __actual__ OOB data has been implemented. An 
application sends a zero length message with MSG_OOB, after that it 
sends some data (not suppose to be OOB data). How is the receiver going 
to differentiate if the data an OOB or not.

THB I've never written any application which would use OOB, so in
practice IDK. But from kernel code and looking at man pages when
OOBINLINE is not set for OOB data to be received MSG_OOB has to be 
set in the recv syscall.

I'd encourage anyone thinking about "using OOB" to read
https://tools.ietf.org/html/rfc6093 first.  Basically, TCP does not
actually provide an OOB mechanism, and frankly Unix sockets shouldn't
try either.

As an aside, we should probably remove the net.ipv4.tcp_stdurg sysctl
since it's broken.

   Some operating systems provide a system-wide toggle to override this
   behavior and interpret the semantics of the Urgent Pointer as
   clarified in RFC 1122.  However, this system-wide toggle has been
   found to be inconsistent.  For example, Linux provides the sysctl
   "tcp_stdurg" (i.e., net.ipv4.tcp_stdurg) that, when set, supposedly
   changes the system behavior to interpret the semantics of the TCP
   Urgent Pointer as specified in RFC 1122. However, this sysctl changes
   the semantics of the Urgent Pointer only for incoming segments (i.e.,
   not for outgoing segments).  This means that if this sysctl is set,
   an application might be unable to interoperate with itself if both
   the TCP sender and the TCP receiver are running on the same host.

quoted

We could use a different flag (MSG_SIGURG) or implement the _actual_ OOB 
data semantics (If anyone is interested in it). MSG_SIGURG could be a 
generic flag that just sends SIGURG irrespective of the length of the data.

No idea on the SIGURG parts :)

If we were going to do something different from TCP sockets to generate
a remote SIGURG, then it would ideally be an entirely different mechanism
(eg a fcntl()) that could also be implemented by pipes.

But I think it's worth just saying "MSG_OOB on Unix sockets generates a
signal on the remote end, just like it does on TCP sockets.  Unix sockets
do not actually support OOB data and behave like TCP sockets with
SO_OOBINLINE set as recommended in RFC 6093".