Messages in this thread | | | Subject | Re: [PATCH] af_unix: Allow Unix sockets to raise SIGURG | From | Shoaib Rao <> | Date | Fri, 29 Jan 2021 12:49:45 -0800 |
| |
On 1/29/21 12:44 PM, 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: >>> On 1/29/21 12:02 PM, Jakub Kicinski wrote: >>>> On Fri, 29 Jan 2021 11:48:15 -0800 Shoaib Rao wrote: >>>>> 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. >> 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. > > 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
> >> >>> 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.
| |