Re: [PATCH v2 2/3] net/handshake: Add support for PF_HANDSHAKE

[Jakub Kicinski <kuba@kernel.org>]

On Tue, 31 Jan 2023 15:18:02 +0000 Chuck Lever III wrote:
> > On Jan 30, 2023, at 11:35 PM, Jakub Kicinski <kuba@kernel.org> wrote:
> > On Sat, 28 Jan 2023 14:06:49 +0000 Chuck Lever III wrote:  
> >> poll/listen/accept is the simplest and most natural way of
> >> materializing a socket endpoint in a process that I can think
> >> of. It's a well-understood building block. What specifically
> >> is troubling you about it?  
> > 
> > poll/listen/accept yes, but that's not the entire socket interface. 
> > Our overall experience with the TCP ULPs is rather painful, proxying
> > all the other callbacks here may add another dimension.  
> >
> > Also I have a fear (perhaps unjustified) of reusing constructs which are
> > cornerstones of the networking stack and treating them as abstractions.  
> 
> OK, then I take this as a NAK for listen/poll/accept in
> any form. I need some finality here because we need to
> move forward.

To be clear - if Paolo, Eric or someone else who knows the socket layer
better than I do thinks that your current implementation is good then 
I won't stand in the way. 

> >  kernel                          user space
> > 
> >   notification     ---------->
> > (new connection awaits)
> > 
> >                    <----------
> >                                  request (target fd=100)
> >   
> >                    ---------->  
> >   reply
> > (fd 100 is installed;
> >  extra params)  
> 
> What type of notification do you prefer for this? You've
> said in the past that RT signals are not appropriate. It
> would be easy for user space to simply wait on nlm_recvmsg()
> but I worry that netlink is not a reliable message service.

There are various bits and bobs in netlink which are supposed to help.
A socket which subscribed to notifications should get an error if a
delivery fails (netlink_overrun()). The kernel commonly supports a GET
request which the user space can exercise after missing notifications 
to get back in sync.

> And, do you have a preferred mechanism or code sample for
> installing a socket descriptor? 

I must admit - I don't.