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

On 1/29/21 11:54 AM, Shoaib Rao wrote:

On 1/29/21 11:19 AM, Matthew Wilcox wrote:

quoted

On Fri, Jan 29, 2021 at 09:56:48AM -0800, Shoaib Rao wrote:

quoted

On 1/25/21 3:36 PM, Jakub Kicinski wrote:

quoted

On Fri, 22 Jan 2021 15:06:37 +0000 Matthew Wilcox (Oracle) wrote:

quoted

From: Rao Shoaib <redacted>

TCP sockets allow SIGURG to be sent to the process holding the other
end of the socket.  Extend Unix sockets to have the same ability.

The API is the same in that the sender uses sendmsg() with MSG_OOB to
raise SIGURG.  Unix sockets behave in the same way as TCP sockets 
with
SO_OOBINLINE set.

Noob question, if we only want to support the inline mode, why 
don't we
require SO_OOBINLINE to have been called on @other? Wouldn't that
provide more consistent behavior across address families?

With the current implementation the receiver will also not see MSG_OOB
set in msg->msg_flags, right?

SO_OOBINLINE does not control the delivery of signal, It controls how
OOB Byte is delivered. It may not be obvious but this change does not
deliver any Byte, just a signal. So, as long as sendmsg flag contains
MSG_OOB, signal will be delivered just like it happens for TCP.

I don't think that's the question Jakub is asking.  As I understand it,
if you send a MSG_OOB on a TCP socket and the receiver calls recvmsg(),
it will see MSG_OOB set, even if SO_OOBINLINE is set.

No it wont. Application just gets a signal.

quoted

   That wouldn't
happen with Unix sockets.  I'm OK with that difference in behaviour,
because MSG_OOB on Unix sockets _is not_ for sending out of band data.
It's just for sending an urgent signal.

That is what I just explained in my email

quoted

As you say, MSG_OOB does not require data to be sent for unix sockets
(unlike TCP which always requires at least one byte), but one can
choose to send data as part of a message which has MSG_OOB set. It
won't be tagged in any special way.

To Jakub's other question, we could require SO_OOBINLINE to be set.
That'd provide another layer of insurance against applications being
surprised by a SIGURG they weren't expecting.  I don't know that it's
really worth it though.

SO_OOBINLINE has a meaning, that the urgent byte is part of the stream 
and using SO_OOBLINE to allow signalling would be wrong/confusing. We 
could add a socket option on the receiver to indicate if it supports 
or wants the signal.

quoted

One thing I wasn't clear about, and maybe you know, if we send a 
MSG_OOB,
does this patch cause this part of the tcp(7) manpage to be true for
unix sockets too?

        When out-of-band data is present, select(2) indicates the 
file descrip‐
        tor as having an exceptional condition and poll (2) indicates 
a POLLPRI
        event.

No because there is no data involved. Poll is associated with data not 
signals.

Shoaib

SO_OOBINLINE implies there is urgent data inline -- This patch will send 
a signal even if there is no data.

Shoaib

quoted