On Fri, 29 Jan 2021 12:10:21 -0800 Shoaib Rao wrote:Correct.
On 1/29/21 12:02 PM, Jakub Kicinski wrote:Okay. Let me try again. AFAICS your code makes it so that data sent
On Fri, 29 Jan 2021 11:48:15 -0800 Shoaib Rao wrote:The code does not care about the size of data -- All it does is that if
Data was discarded because the flag was not supported, this patchWhen you say it does not support any urgent data do you mean the
changes that but does not support any urgent data.
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.
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)
with MSG_OOB is treated like any other data. It just sends a signal.
So you're hijacking the MSG_OOB to send a signal, because OOB alsoCorrect.
sends a signal.
But there is nothing OOB about the data itself.Correct.
SoYes I can do that.
I'm asking you to make sure that there is no data in the message.
That way when someone wants _actual_ OOB data on UNIX sockets they
can implement it without breaking backwards compatibility of the
kernel uAPI.
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.