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

[Shoaib Rao]

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