Re: RPC-with-TLS client does not receive traffic

[Jakub Kicinski <kuba@kernel.org>]

On Sat, 17 May 2025 12:39:58 -0400 Chuck Lever wrote:
> > Hm, yes, my intuition would be to add a xs_poll_check_readable() 
> > after connection set up to check if we raced with data being queued?
> > 
> > IIUC sk->sk_user_data is not set up when the first event fires
> > so xs_data_ready() ignores it?  We can't set user_data sooner?  
> 
> I think the answer to this is that sunrpc never sees a data ready event.
> The value contained in sk->sk_user_data is therefore irrelevant.
> 
> Because tls_setsockopt() sets strp->msg_ready, when the underlying
> socket event arrives tls_data_ready() is a no-op. That terminates the
>  ->data_ready call chain before xs_data_ready can be called.  
> 
> The handshake daemon sets the session key by calling tls_setsockopt.
> When it hangs:
> 
> function:             tls_setsockopt
> function:                do_tls_setsockopt_conf
> function:                   tls_set_device_offload_rx
> function:                   tls_set_sw_offload
> function:                      init_prot_info
> function:                      tls_strp_init
> function:                   tls_sw_strparser_arm
> function:                   tls_strp_check_rcv
> function:                      tls_strp_read_sock
> function:                         tls_strp_load_anchor_with_queue
> function:                         tls_rx_msg_size
> function:                            tls_device_rx_resync_new_rec
> function:                         tls_rx_msg_ready    <<<<<
> 
> The next call to tls_data_ready sees strp->msg_ready is set, returns
> without doing anything, and progress stops.
> 
> In the successful case, tls_strp_check_rcv() simply returns, leaving
> strp->msg_ready set to zero. The next call to tls_data_ready can
> then process the ingress data and call xs_data_ready.

Is there any data queued on the TLS socket already when it "hangs" ?
If it's getting into msg_ready state without the data - it's a bug 
in TLS. If there's a full record queued at the time when handshake
passes the socket back to the kernel - it's up to the reader to read
the already queued data out.