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

On Dec 7, 2020, at 8:35 AM, Matthew Wilcox [off-list ref] wrote:

On Sat, Nov 28, 2020 at 08:02:37PM -0800, Andy Lutomirski wrote:

quoted

quoted

On Sat, Nov 28, 2020 at 7:07 PM [off-list ref] 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.

quoted

quoted

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

Oh, you have thousands of clients and each client has its own server thread. Lovely.

quoted

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

Fair enough.

quoted

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.

quoted

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.

quoted

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.

So maybe this is okay. It does seem like a hack, but maybe it’s a hack that’s not too bad to support in the kernel.