Re: so_rerror

[christos%zoulas.com@localhost (Christos Zoulas)]

On Nov 3, 11:39pm, roy%marples.name@localhost (Roy Marples) wrote:
-- Subject: Re: so_rerror

|  From what ships with NetBSD I think only bind we missed and now fixed?
| So that just leaves syslogd as the outlier which you have constantly 
| complaied about. I know that other logging systems set the receive 
| buffer to the biggest they can and supply options to set a runtime size 
| - both options would surely help here.

Well, I did not find bind, but with syslogd the situation needs
different handling; i.e. don't even bother to log if you are dropping
on receive because you (syslogd) are making things worse.

| I've not seen or heard about any other programs that need addressing, 
| other than the various ATF test cases that have been added. Can you give 
| examples please?

I have not seen any.

| bind was excplicity designed to handle this prior to my change, however 
| the bind design wasn't great and just closed the socket.
| recv returning ENOBUFS has been documented by POSIX many years before my 
| change to NetBSD so it can be argued that not handling it gracefully is 
| not standards compliant.

Well, I think that the bind behavior was a bug. It is just that
the authors did not expect ENOBUFS on recv, so they thought if it
happened it was fatal (needed resetting the socket).

| Using the same logic you put forward we should set 
| security.pax.mprotect.enabled=0 because I have a list of programs that 
| don't work with it and when trying to poke people to get it to work they 
| said just disable that option.

With 2 major differences:

1. pax-mprotect protects the system from random programs that misuse
   mmap; the class of programs that breaks is small and known (jit stuff);
   the majority of people think that the default should be on. And finally
   there is a sysctl to choose... Until I commit the code, the new behavior
   for sockets is mandatory.
2. so_rerror affects random programs (we don't know which ones but any
   one using sockets can be affected; this set is much larger than the
   set of programs that mmap +x). The majoriry of people think that the
   default behavior should be to ignore the error.

The straw that broke my back was that I had to change stuff around
so that my timemachine backups could work again. I.e. the change
actually broke things (by making the the backup bandwidth effectively 0).

Let's remember that I was not initially against the change and I
tried for a long time to fix whatever broke... And I was the one
that increased buffers for many things. It is just that increasing
buffers does not fix the problem in pathological cases, and also
wastes resources.

Nevertheless now everyone can have it the way the like... There is
a sysctl to turn it on globally and a per-socket setsockopt to override.

christos