Re: [RFC net-next af_unix v1 0/1] Allow delivery of SIGURG on AF_UNIX streams socket

[Matthew Wilcox <willy@infradead.org>]

On Sat, Nov 28, 2020 at 08:02:37PM -0800, Andy Lutomirski wrote:
> On Sat, Nov 28, 2020 at 7:07 PM <rao.shoaib@oracle.com> wrote:
> > We have a use case where thousands of processes connect locally to a
> > database and issue queries that are serviced by a pool of threads.
> > Communication is done over AF_UNIX sockets. Currently, there is no way
> > for the submitter to signal the servicing thread about an urgent
> > condition such as abandoning the query.
> 
> Sure there is.  You could close() the socket.  You could send() a
> message saying that your query wants to be canceled.  You could use a
> second socket for this if it's somehow inconvenient to do it with a
> single socket.

The application already works with SIGURG (and TCP, obviously).  Yes,
it could be changed to use one of these other methods, but they're all
more inconvenient to use than SIGURG.

> > This patch addresses that
> > requirement by adding support for MSG_OOB flag for AF_UNIX sockets.
> > On receipt of such a flag, the kernel sends a SIGURG to the peer.
> 
> SIGURG is a horrible interface.  It doesn't scale -- signals are slow,
> and they give no indication of *which* socket has urgent data.

It doesn't need to scale.  This is "client wishes to abort the operation",
just like telnet.  Each thread only has one socket (and, thanks to
F_SETOWN_EX, signals for that socket get directed to that thread).

> Aside
> from this, the "urgent" interface itself is nuts -- even the TCP RFCs
> and implementations seem unable to agree on exactly how to tell
> *which* data is urgent.

That doesn't matter.  Unix sockets with MSG_OOB behave like they
have had SO_OOBINLINE which is the recommendation from
https://tools.ietf.org/html/rfc6093

> At least epoll might be a scalable way to
> tell which socket has urgent data, but that's not what your patch
> description seems to be talking about.

epoll is the wrong interface for this application, as far as I can tell.

> Oh yeah, SIGURG simply doesn't work across privilege boundaries.

Please elaborate.  SIGURG is default-ignore, so you have to enable a
handler for it.  And you have to call SETOWN to receive a signal.

> I'm also a bit nervous that there might be some program out there that
> expects SIGIO but not SIGURG on unix sockets, and you're breaking
> them.

The only incompatible scenario I've been able to think of is an
application which has both TCP and Unix sockets will suddenly get its
SIGURG handler called for Unix sockets when it's only expecting to get
it called for TCP sockets.  That feels like a very unlikely scenario.