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

On 1/29/21 12:44 PM, Shoaib Rao wrote:

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

quoted

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

quoted

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

quoted

On Fri, 29 Jan 2021 11:48:15 -0800 Shoaib Rao wrote:

quoted

Data was discarded because the flag was not supported, this patch
changes that but does not support any urgent data.

When you say it does not support any urgent data do you mean the
message len must be == 0 because something is checking it, or that
the code does not support its handling?

I'm perfectly fine with the former, just point me at the check, 
please.

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.

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.

Shoaib

There is a relevant issue that I want to point out, Is it acceptable to 
send SIGURG without the receiver having any means to know what the 
urgent condition is?

Shoaib

quoted

quoted

while (sent < len) {
                  size = len - sent;
<..>

}

          if (msg->msg_flags & MSG_OOB)
                  sk_send_sigurg(other);

Before the patch there was a check above the while loop that checked 
the
flag and returned and error, that has been removed.