On 1/29/21 1:18 PM, Jakub Kicinski wrote:
On Fri, 29 Jan 2021 12:44:44 -0800 Shoaib Rao wrote:
On 1/29/21 12:18 PM, Jakub Kicinski wrote:
On Fri, 29 Jan 2021 12:10:21 -0800 Shoaib Rao wrote:
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.
So you're hijacking the MSG_OOB to send a signal, because OOB also
sends a signal.
Correct.
But there is nothing OOB about the data itself.
Correct.
So
I'm asking you to make sure that there is no data in the message.
Yes I can do that.
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.
Thinking a little more about your suggestion, I think it can work but
the application will have to do some more work to differentiate. I would
prefer it would not have to. Anyways, I will re-submit the patch with
the zero length check.
Thanks a lot for your comments,
Shoaib
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 :)
