Re: so_rerror

[Roy Marples <roy%marples.name@localhost>]

On 03/11/2018 15:33, Christos Zoulas wrote:
> Hello,
>
> Since the introduction of so_rerror tracking to detect receive
> socket overflows, we have been trying to make other programs cope
> by increasing their buffer sizes and avoid the error message flood.
> We have taken this as far as it goes now, and still there are
> pathological cases where the new behavior cannot easily be fixed
> (one has to go and fix each program separately). One example is
> when a program turns on debugging to syslog and logs quicker than
> syslog can absorb. What happens then is that syslog and the program
> keep spewing error messages about the socket overflow and do little
> else...

This is a double edged sword.
If there's any issue logging messages, I want to know about it.
I have no idea if the discarded message was pointless debug or someone 
trying to breach my server. A good example is on one high traffic server 
I have the bulk of text in /var/log/messages is from blacklistd - I 
would be upset if any of that was silently discarded.
Maybe we need an option to increase the size of syslogd buffers?

Or better yet, we need a way of dynamically increasing/descreasing the 
buffers in the kernel to avoid this.

> While keeping track of receive overflows maybe desired (in the
> routing socket + dhcpcd case), I think since it is a new behavior
> it should be optional; programs that want to know about it should
> turn it on. This patch restores the original behavior and allows
> program who care about receive errors to arrange to be notified by
> introducing setsockopt SO_RERROR.

I have no issue with each program defining the behaviour it wants.
However, I do want an option to enable it globally, like a sysctl option 
so I can tell when syslogd isn't doing it's job properly - or any other 
application for that matter.

If you want this new global option to default to off (which I strongly 
disagree with - sweeping issues under the carpet should not be a default 
option), then can we also have a man page update to describe this 
behaviour please.

> Best,
>
> christos
>
> Index: kern/uipc_socket.c
> ===================================================================
> RCS file: /cvsroot/src/sys/kern/uipc_socket.c,v
> retrieving revision 1.265
> diff -u -u -r1.265 uipc_socket.c
> --- kern/uipc_socket.c	3 Sep 2018 16:29:35 -0000	1.265
> +++ kern/uipc_socket.c	3 Nov 2018 15:22:19 -0000
> @@ -1757,6 +1757,7 @@
>   	case SO_OOBINLINE:
>   	case SO_TIMESTAMP:
>   	case SO_NOSIGPIPE:
> +	case SO_RERROR:
>   #ifdef SO_OTIMESTAMP
>   	case SO_OTIMESTAMP:
>   #endif
> @@ -1958,6 +1959,7 @@
>   	case SO_OOBINLINE:
>   	case SO_TIMESTAMP:
>   	case SO_NOSIGPIPE:
> +	case SO_RERROR:
>   #ifdef SO_OTIMESTAMP
>   	case SO_OTIMESTAMP:
>   #endif
> Index: kern/uipc_socket2.c
> ===================================================================
> RCS file: /cvsroot/src/sys/kern/uipc_socket2.c,v
> retrieving revision 1.132
> diff -u -u -r1.132 uipc_socket2.c
> --- kern/uipc_socket2.c	3 Sep 2018 16:29:35 -0000	1.132
> +++ kern/uipc_socket2.c	3 Nov 2018 15:22:19 -0000
> @@ -509,7 +509,8 @@
>   	KASSERT(solocked(so));
>   
>   	so->so_rcv.sb_overflowed++;
> -	so->so_rerror = ENOBUFS;
> +	if (so->so_options & SO_RERROR)
> +		so->so_rerror = ENOBUFS;
>   	sorwakeup(so);

Waking up the socket without so->so_rerror being set is a waste of CPU.

>   }
>   
> ===================================================================
> RCS file: /cvsroot/src/sys/sys/socket.h,v
> retrieving revision 1.128
> diff -u -u -r1.128 socket.h
> --- sys/socket.h	16 Sep 2018 20:40:20 -0000	1.128
> +++ sys/socket.h	3 Nov 2018 15:22:19 -0000
> @@ -132,6 +132,7 @@
>   #define	SO_NOSIGPIPE	0x0800		/* no SIGPIPE from EPIPE */
>   #define	SO_ACCEPTFILTER	0x1000		/* there is an accept filter */
>   #define	SO_TIMESTAMP	0x2000		/* timestamp received dgram traffic */
> +#define	SO_RERROR	0x4000		/* Keep track of receive errors */
>   
>   
>   /*

Roy