Re: so_rerror

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

On 08/11/2018 03:16, Jason Thorpe wrote:
> > On Nov 7, 2018, at 7:10 PM, Roy Marples <roy%marples.name@localhost 
> > <mailto:roy%marples.name@localhost>> wrote:
> >
> > And packets were dropped for AF_LOCAL otherwise it wouldn't see any 
> > overflow errors, but yet it does (for SO_RERROR).
>
> Shall we take a step back for a moment?
>
> Any sane AF_LOCAL implementation would treat lack of space on the 
> receive side as equivalent to lack of space on the sending side, because 
> I mean why on earth would you keep multiple copies of the data you're 
> trying to send?  I don't see any reason why in the AF_LOCAL case there 
> would be anything other than a receive buffer, and a "send" is really 
> just an sbappend() or sbappendrecord() (or whatever those functions are 
> called these days) to the receiver.
>
> It's the SENDER that should rightfully see the error in the AF_LOCAL case.
>
> Am I missing something?

Thanks for providing some sanity.
And providing a use case where the medium does play a role in affecting 
the protocol!

I've changed the error path so that soroverflow is not called if the 
error is returned directly to the sender when it's 1:1 .... as is the 
case for sys/kern/uipc_usrreq.c and sys/netipsec/keysock.c

Now Christos's test case reports no lossage.

Roy