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

[Shoaib Rao <rao.shoaib@oracle.com>]

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 :)