Messages in this thread | | | Subject | Re: [PATCH] af_unix: Allow Unix sockets to raise SIGURG | From | Shoaib Rao <> | Date | Fri, 29 Jan 2021 13:54:43 -0800 |
| |
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 :)
| |